3 ms·
[Not converging on SQL] only makes life harder for everyone. No, it makes life harder for people trying to use off-the-shelf ORMs and other RDBMS tools. I wou
by evgen 17y ago
[Not converging on SQL] only makes life harder for everyone.
No, it makes life harder for people trying to use off-the-shelf ORMs and other RDBMS tools. I would much rather make life harder for them than make it harder for the developers of these databases.
I don't see anything bad about SQL (the language) that would prevent it from taking this role.
I, for one, do not think that it is expressive enough to cover all of the different paradigms being explored. It is based on a row/column view of the data that may not be appropriate and which may require additional hoops to be jumped through in order to get the data presentable for the assumptions that SQL makes. Who would be responsible for these transformations? IMHO it should be the end-user, but if SQL gains traction any time soon the db developers will be repeatedly browbeaten by DBAs who can't comprehend why anyone would not share their viewpoints regarding data structuring and could you please make things look like the RDBMs systems we are used to kthxbye...
Adding SQL seems to offer very little at this point except future headaches.
- moe 17y agoI, for one, do not think that it is expressive enough to cover all of the different paradigms being explored. You are not alone with that opinion, I've seen it a couple times in similar discussions. Yet I'm missing a concrete example for a piece of functionality that can't be reasonably wrapped. Browbeating is irrelevant in either direction. What matters for adoption is a sane interface for day-to-day use and that includes proper tooling for interactive use - an area where many of the contenders are still sorely lacking.