We Can Do Better Than SQL

Post by indecisive_user » Tue, Aug 11, 2020, 2:52 PM UTC

feikname wrote: post #286

kd5bjo wrote: post #230

Earlier quoted context omitted.

> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…

> My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order. Most western languages maybe, but according to wikipedia[1] the most common is actually SOV rather than SVO. [1] https://en.wikipedia.org/wiki/Word_order#Distribution_of_wor...

Post by lostjohnny » Tue, Aug 11, 2020, 2:55 PM UTC

013a wrote: post #336

tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

    db.orders.aggregate([
       {
          $lookup:
             {
               from: "warehouses",
               let: { order_item: "$item", order_qty: "$ordered" },
               pipeline: [
                  { $match:
                     { $expr:
                        { $and:
                           [
                             { $eq: [ "$stock_item",  "$$order_item" ] },
                             { $gte: [ "$instock", "$$order_qty" ] }
                           ]
                        }
                     }
                  },
                  { $project: { stock_item: 0, _id: 0 } }
               ],
               as: "stockdata"
             }
        }
    ])

    SELECT *, stockdata
    FROM orders
    WHERE stockdata IN (SELECT warehouse, instock
                        FROM warehouses
                        WHERE stock_item= orders.item
                        AND instock >= orders.ordered );

Post by sanderjd » Tue, Aug 11, 2020, 3:00 PM UTC

Certhas wrote: post #325

sanderjd wrote: post #289

Earlier quoted context omitted.

> It should be possible for an amateur to quickly write an SQL validator as a starting project ...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as…

Your last paragraph is non sequitur. It is perfectly possible for the syntax to not be the interesting part, and for SQL to have been successful despite bad syntax. The underlying idea is brilliant, so the first syntax that exposed it sufficiently well got baked in as a path dependency, even though the syntax sucks.

Post by jolux » Tue, Aug 11, 2020, 3:05 PM UTC

throwaway894345 wrote: post #347

jolux wrote: post #339

Earlier quoted context omitted.

That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.

And those ORMs have to deal with the SQL composability issues as well, often to the effect of dramatically poorer performance.

Post by petepete » Tue, Aug 11, 2020, 3:10 PM UTC

lostjohnny wrote: post #353

013a wrote: post #336

Earlier quoted context omitted.

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

> I would point to MongoDB's query language seriuosly? db.orders.aggregate([ { $lookup: { from: "warehouses", let: { order_item: "$item", order_qty: "$ordered" }, pipeline: [ { $match: { $expr: { $and: [ { $eq: [ "$stock_item", "$$order_item" ] }, { $gte: [ "$instock", "$$order_qty" ] } ] } } }, { $project: { stock_item: 0, _id: 0 } } ], as: "stockdata" } } ]) VS SELECT *, stockdata FROM orders WHERE stockdata IN (SE…