1. 12
  1.  

  2. 6

    osquery reminds me a lot of WMI’s query language. Likewise, in the IBM i world, there’s been a big push to expose system APIs as SQL functions or tables, to make it easier for DBAs and Unix-side programs to access said APIs.

    I think assuming relational DBs need SQL is kinda limiting. QUEL existed, and I think it’d be great if we could have a NoSQL RDBMS - that is, a relational DB (since relational data is good and fits many problem domains) without SQL (which is a bit of a crufty language, and could be replaced with a language learning from its mistakes or simply having none and relying on program-side query builders serializing to a “raw” query language).

    1. 2

      I feel like I found my dev soulmate reading that comment. I feel exactly the same.

      1. 1

        There is also logparser which may be a better example of how it can be applied across many types of input/source.

        1. 1

          I think assuming relational DBs need SQL is kinda limiting. QUEL existed, and I think it’d be great if we could have a NoSQL RDBMS - that is, a relational DB (since relational data is good and fits many problem domains) without SQL (which is a bit of a crufty language, and could be replaced with a language learning from its mistakes or simply having none and relying on program-side query builders serializing to a “raw” query language).

          We kind of have that over in the Windows world via things like LINQPad, or just the LINQ APIs in .NET in general. You can use LINQ to query databases, WMI, arbitrary raw data, and so on, irrespective of source, and with relatively unsurprising performance. I could also make a case with a straight face that MongoDB is indeed, or at least has the potential to be, a NoSQL RDBMS.

          But you’re right that we’re not really there on either front in a general sense.

        2. 3

          I feel like you could make a language that’s just SQL with the SELECT statements last and it would be so much easier to use and learn, except it will never catch on because it’s just SQL with the SELECT statements last.

          1. 3

            There was such query language - QUEL. Now there are query builders projects (like Ecto or jOOQ) that supports more “free form” ordering of the statements in query and make these feel much more “natural”, for example in Ecto you write:

            from s in "stories",
              as: :story,
              left_join: votes in subquery(count_query("votes")),
              on: votes.story_id == s.id,
              left_join: flags in subquery(count_query("flags")),
              on: flags.story_id == s.id,
              left_join: comments in subquery(count_query("comments")),
              on: comments.story_id == s.id,
              inner_join: tags in subquery(tags_query),
              on: tags.story_id == s.id,
              order_by: [desc: fragment("hotness"), desc: :inserted_at],
              select: %{
                story_id: s.id,
                hotness:
                  (1 + tags.mod) * (coalesce(votes.count, 0) - coalesce(flags.count, 0)) * 3600 /
                    fragment("EXTRACT(epoch FROM (now() - ?))", s.inserted_at),
                inserted_at: s.inserted_at
              }
            

            Which is rough equivalent to:

            SELECT
              story.id AS id,
              (1 + tags.mod) * (coalesce(votes.count, 0) - coalesce(flags.count, 0)) * 3600 / EXTRACT(epoch FROM (NOW() - story.inserted_at) AS hotness,
              inserted_at: story.inserted_at
            FROM stories AS story
            LEFT JOIN (
              SELECT
                story_id,
                COUNT(*)
              FROM votes
              GROUP BY story_id
            ) AS votes
            -- rest of the joins omited for brevity
            ORDER BY hotness DESC, inserted_at DESC
            
            1. 1

              Or the same query in Preql -

                  leftjoin(story: stories, votes: votes{.story_id => count()}, flags: flags_count)
                  {
                    id: .story.id
                    hotness: (1 + .tags.mod) * ((.votes.count or 0) - (.flags.count or 0)) * 3600 / (now() - .story.inserted_at).epoch
                    inserted_at: .story.inserted_at
                  } 
                  order {^hotness, ^inserted_at}
              
          2. 3

            NoSQL was too antagonizing of a word to start with. We start from a fighting stance as people are exposed to learning an alternative but not opposing approach. To me, it should have meant Not Only SQL from the start. Yes, the query language isn’t the critical detail and mongo in particular is so close you can almost have a tourist translation book handy as you visit.

            1. 1

              Couchbase is a non-relational document database but uses a very-close-to-SQL query language called N1QL (“Non-1st-normal-form Query Language”.) The biggest differences are extensions to support accessing nested properties in JSON.