Database Startup Idea: Dynamic Relational

1 points by tabtab ↗ HN
Over at the c2.com wiki, the idea of "Dynamic Relational" was explored. You DON'T need a DBA: columns and tables are Create-On-Write, unless you start adding constraints to make it act more like a traditional RDBMS: as a project matures, you can incrementally "lock it down". Such a tool would be great for start-up projects and situations where the requirements are still fuzzy.

Conceptually you can think of each row as an XML statement. For example, an employee record could be represented as:

  <employee lastname="Li" firstname="Joe" salary="120000" id="318"/>
This does not imply it has to be implemented as XML, it's just a handy conceptualization. It's possible to use SQL as the query language, with some minor tweaks. For example, one has to be careful about comparisons because of the implied type model. But other than type handling, users of a Dynamic Relational system would feel right at home because they can leverage most of their existing RDBMS and SQL knowledge.

If you ask for a non-existing column, such as "SELECT madeUpColumn FROM employee", the result column would be blank or null. That is unless one adds constraints that forbid undefined columns on a given table. Also, people disagree if and how to implement nulls. I'd suggest make null-handling a configuration switch.

If you did "SELECT * FROM employee", the result table would have all the columns found in the "employee" rows. In a typical CRUD application, you probably should use explicit columns in the SELECT clause.

Now, if somebody would just build such a database system...

4 comments

[ 3.9 ms ] story [ 19.9 ms ] thread
How would this be different from a SQL interface on top of a NOSQL database.

https://drill.apache.org/ ?

Most NOSQL databases are non-relational such that you have to deal with "impedance mismatches". They can have duplicate columns and duplicate rows, for example, which SQL itself is not designed to handle without adding ugly kludges. It's even messier for writes. I didn't mention it due to posting size limits, but each Dynamic Relational table has an auto-generated "ID" column so that each row is unique. Good question!
I'm not sure what those solve. Dynamic Relational (DR) is relational so that one can use SQL on it without big impedance mismatches. Your links appear to be tying to invent a NON-relational version(s) of SQL, but they are too different from SQL and existing RDBMS to be easy to learn.

DR's goal is to match/fit relational, existing RDBMS, and SQL as much as possible, yet still be dynamic. Non-relational databases and non-relational query languages probably will fail at that goal. They deviate from RDBMS too much because they are changing too many things. DR only deviates just enough from traditional RDBMS to get dynamism so that users of RDBMS can easily learn/use it withOUT tossing out most their RDBMS, relational, and SQL knowledge. It just reinvents one nation, not the entire database world.