4 ms·
Well, the first problem you'll run into is, which SQL implementation do you use? I think pretty much all discussion of the topic stops here since there are so m
by captain-asshat 15y ago
Well, the first problem you'll run into is, which SQL implementation do you use? I think pretty much all discussion of the topic stops here since there are so many differences between the actual SQL standard and what the varios modern RDBMS' actually use.
The only real way past this hurdle is to create an intermediate SQL parser that uses your own interpretation of the standard, and at this point you may as well just use OData.
I'm not sure how valuable a discussion about just using the SQL implementation that comes with your RDMBS is, as doing this defeats all the effort we put into making our front ends ignorant of the underlying schema by locking the front-end into a specific SQL implementation for queries.
- deleted 15y ago[deleted]
- 6ren 15y agoThat's a practical, real problem, yes. But something with the equivalent power of a relational algebra (e.g. SQL) seems needed, if web APIs are to be used by many different clients, and be back-compatible. It's true that some aspects are different from those problems in an enterprise that SQL were designed to address (e.g. the web crosses companies; massive numbers of users; rarely mission-critical), so perhaps SQL itself won't be the ideal solution Even if it was, the usual approach of our industrial is to invent new standards whenever possible (new firms may do this partly to lock out old ones). But it seems that the solution must be conceptually identical: an sufficiently expressive data model (e.g. relations), and a way to map between different representations with that data model (e.g. relational algebra).