Aaeriele wrote:You are describing a document-based data store like CouchDB. This is essentially how querying such stores works for anything beyond simple key->value lookups - you write a script which emits the results you want.
There are upsides and downsides to this. The upside is that you get a much more programmatic rather than expression-based query system. The downside is that you basically no longer get the benefits of a query planner.
This would still be for relational data, and still would be used with ACID compliant RDBMS, all you are changing is how you write the query. It's still a declarative language; all of the statements except for the very last are simply defining the query itself and not actually querying anything. You would get all the benefits of the query planner, just something easier to read (well, for complex queries) and more flexible.
One of the main reasons I came up with this is actually because of the inefficiencies of SQL; you can't dynamically build a query in a clean way (you have to build the statement as a string and call exec; blech). It's a common problem; how to have multiple queries depending on different parameter. Let's say you want to search by phone number or address or last name - you can either have a separate query for each combination of options, get lists of IDs for data into a temp table and then join to the temp table, or have a bunch of crap in the where clause (which the DBMS will likely choose to use and cache a generic execution plan). The first is going to perform best, but is copy-paste hell, the second is going to perform okay, and the third is going to perform horribly. With a language built around constructing queries as a series of statements, then you can build your query, much like you would if you did exec, but without all the horribleness.
Also, if I did build it, I would also add in a way to do parent-child relationships. Something along these lines:
Code: Select all
Query.Children = MySchema.Table2(b,c,d) : a = Query.a;
Instead of constructing as a giant table, you can choose a more accurate representation of the relationship with no duplicate data or extra queries.
Summum ius, summa iniuria.