Dynamic Relational

"We should not impose regularity where it does not exist." --TedNelson

Giving relational dynamic character that is roughly analogous to dynamically-typed or type-free programming languages. (The "Oracle model" is more analogous to static or strong-typed languages.) Column existence, and perhaps table existence can also optionally be dymnamic.

MultiParadigmDatabase describes the basic ideas behind DynamicRelational, but adds (or subtracts) features to accommodate OOP. Since the mixture of dynamism and OO features tended to confuse people, I felt a dedicated topic was in order. (Dynamism seemed necessary there to allow such a database to accommodate more paradigms.) Thus, for a working definition of dynamic relational, lets exclude these features from MultiParadigmDatabase:

But these features are kept:

Optional features include:

TupleDefinitionDiscussion argues that dynamic records don't really violate the "tuple" requirement of relational because one can conceptually view such as an ever-changing traditional "rigid" rectangular view. It may hurt your brain a little to think of it that way, or burn CPU to get a full rectangle, but it still manages to keep it technically honest to relational rules. Relational does not dictate that schemas never change.

Tips for adapting ODBC drivers and/or SQL for dynamism are given in links near the bottom of MultiParadigmDatabase.


SqLite seems the closest existing product to this idea, although only the cell "types" are dynamic, not the schema. Schemas must be declared and updated explicitly.

Some also suggest that ProLog creates or infers ad-hoc relational or relational-like structures.

Yeah dbdebunk.com really thinks highly of SQLite... http://www.dbdebunk.com/quotes2004.html

Comparison operator discussion and examples moved to ComparingDynamicVariables.

This article describes DynamicRelational-like techniques that are becoming popular:


But, it does not call the alleged alternatives "relational". One possible reason can be seen in one of the examples that violated uniqueness in column name per record, such as having two colors for a car. If they instead supplied "color_1" and "color_2", then the unique column name requirement would not be violated, keeping it true relational (or at least closer to it). I wonder if they have a good reason to abandon unique attribute names per row. And some of them look more like an EssExpressionDatabase (rows of nested lists), which is a curious idea, but not "relational". --top

Examples of optional/incremental "lock-down" constraints:
Possible uses:
See also: ObjectsAreFromMarsTablesAreFromVenus, DoesRelationalRequireTypes, MaspBrainstorming, NoSql, MultiParadigmDatabase

CategoryRelationalDatabase, CategoryLanguageTyping, CategorySpeculative

EditText of this page (last edited April 14, 2014) or FindPage with title or text search