
Database Startup Idea: Dynamic Relational - tabtab
Over at the c2.com wiki, the idea of &quot;Dynamic Relational&quot; was explored. You DON&#x27;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 &quot;lock it down&quot;. Such a tool would be great for start-up projects and situations where the requirements are still fuzzy.<p>Conceptually you can think of each row as an XML statement. For example, an employee record could be represented as:<p><pre><code>  &lt;employee lastname=&quot;Li&quot; firstname=&quot;Joe&quot; salary=&quot;120000&quot; id=&quot;318&quot;&#x2F;&gt;
</code></pre>
This does not imply it has to be implemented as XML, it&#x27;s just a handy conceptualization. It&#x27;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.<p>If you ask for a non-existing column, such as &quot;SELECT madeUpColumn FROM employee&quot;, 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&#x27;d suggest make null-handling a configuration switch.<p>If you did &quot;SELECT * FROM employee&quot;, the result table would have all the columns found in the &quot;employee&quot; rows. In a typical CRUD application, you probably should use explicit columns in the SELECT clause.<p>Now, if somebody would just build such a database system...
======
dhanainme
How would this be different from a SQL interface on top of a NOSQL database.

[https://drill.apache.org/](https://drill.apache.org/) ?

~~~
tabtab
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!

~~~
PaulHoule
see [https://www.arangodb.com/](https://www.arangodb.com/) and also
[http://www.w3.org/TR/sparql11-query/](http://www.w3.org/TR/sparql11-query/)

~~~
tabtab
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.

