Separation Of Database And Domain Math

(Moved from SimplifyingRdbms)

One idea proposed in DoesRelationalRequireTypes is to separate the relational engine (or at least the relational interface) from the "domain math".

The relational engine needs to properly handle (at the very least) value-equality, parsing, and serialization to perform its basic duties as a relational engine, all of which require integration of the "domain math".

"Properly handling" some of these is not necessarily the same as implementing. A common interface or set of minimum requirements is certainly in order, but that's expected.

If an RDBMS is to be optimized, various other operators need to roll into the indexing systems and potentially even the transaction support (esp. if using optimistic transactions). While 'separation' has merit (those associated with principles for good CouplingAndCohesion in general) I don't believe it is possible to perform in practice while maintaining these and various other important RDBMS properties.

A more realistic solution might be a relational engine that allows one to integrate new "domain maths" as well as supports syntax extensions required for constructing the necessary queries and updates via DML. One could presumably still support more basic DMLs (e.g. TutorialDee or StructuredQueryLanguage), though some indicator would need to be part of each query as to which language is in use ('using tutorialD;').

I think we are more or less agreeing here. Sometimes the performance is not the bottleneck such that a generic plug-in is sufficient. And even if one needs an efficient domain-specific DBMS that requires built-in core features, there could still be somewhat of a standard or standard template for producing such. Inventing a relational language and DB engine from scratch may not be necessary. A tool could take one 2/3 of the way there.

True, though I don't relish the idea of building domain-specific DBMSs in a manner that is not automatically forward-portable. There are all sorts of configuration management and maintenance issues when branching a project is the only solution available - in particular, advances on one branch require greater effort to port to another branch that might want it, ultimately diminishing productivity return on investment. If at all possible, features necessary to a particular domain that cannot be easily handled by extension should be supported and maintained in the core DBMS so long as the features themselves aren't domain-specific.

In any case, extension mechanisms such as these aren't, at least initially, as simple as supporting tons of stuff in the 'core' engine. They always require a bit of BigDesignUpFront.

It may be practical to support convenient add-ons but not those that require and overhaul of the underlying infrastructure. But as mentioned above, the standards and or existing engine could still serve as a guiding template for a custom DBMS even if the add-on model won't work for a given shop.

As far as parsing, if one can define the domain math in a basic functional style, then perhaps a new parser is not needed. True, you may be stuck with pre-fix notation, but that is not necessarily a big hurdle.

Good point. A functional style would likely serve well for most purposes. The 'parsing' I referred to was less intended towards the operations and more regarding how you express set-values and graph-values and matrix-values, and pattern likenesses (a matrix like <this one>), etc., in the query language. For the most part, unless we can fully anticipate the set of values different domains will use, syntax-specializations will be desirable, even if not entirely necessary.

Of course, there are other benefits of supporting multiple syntaxes. Even you expressed interest in the ability to exchange DMLs from TutorialDee (so you could experiment with TQL) in RelProject. At the moment, most DBMSs seem 'tied' to a DML (usually SQL or their own particular version of it).

One problem with addons is data portability. For example consider a plugin type system where one could extend types (constraints) by plugging in a verification system for a column of data. If this data is ported to some other database that has no constraint/type plugin addon system, or if the data is exported to CSV, fusdx, etc, then the data may not port so well. One could have to define a "standard addon" specification that many databases would support. Most databases take the easy way out and support commonly used constraints such as integer, char, shortstring, etc. In fact most programming languages are similar - the standard constraints available are based on Cee style constraints such as long integers, bytes, chars.

One should generally expect such. If you have a custom type or custom domain math, a different DBMS may have difficulty using the data without using the same math engine. Related: SharingDataIsImportant.

CategoryQueryLanguage