Catalog Of Database Approaches

This is an attempt to catalog all the database (DB) "product" ideas that are floating around this wiki. This is not intended to list components (sub-parts) of databases, but rather more or less complete "database" systems or architectures (intended or actual). It focuses more on the "user" (developer) side and less so on the implementation side (B-trees, etc.), but realizing that UI and implementation are not always completely separable or swappable in database-land because performance usually matters. Similarly, the focus shouldn't be on the database language[2] because they may be more or less swappable. Essentially, this focuses on the underlying conceptual data structures. Please keep it alphabetical and avoid value judgements if possible, linking to debates or proponent materials instead.

DynamicRelational - An experimental idea similar to MultiParadigmDatabase, but where tables are required[1].
NoSql - Somewhat like the MultiParadigmDatabase approach, except that, ACID, joins, and aggregation are not naturally supported or poorly supported for performance reasons. Sometimes it's called "document-centric", but is not always well-defined or varies highly per vender.
MultiParadigmDatabase - An experimental idea which is essentially a giant "map of maps" conceptually. It borrows or mimics parts of existing RDBMS for familiarity and performance purposes. It has a dynamic nature, and explicit tables are optional[1].
ProLog - Queries based on logic statements. (Arguably not a "database" but rather a KnowledgeBase? because the "data" also contains explicit logic expressions.)
RelProject - An OpenSource project to develop an allegedly more "true" or "pure" RelationalDatabase with a RelationalLanguage that implements and extends TutorialDee.
RDBMS - RelationalDatabase Management System - The "traditional" DB, which has been more or less shaped by Oracle and IBM.
TupleSpace - [volunteers for description?]
[more to come...]

Some of these are approaches (e.g., TupleSpace and RDBMS), some are languages (e.g., Prolog), some are products (e.g., RelProject), and some are labels (e.g., NoSql). Wouldn't CategoryDatabase be a sufficient, and maybe better, gathering point for this arbitrary collection of database-related terminology?

Those that are too specific perhaps should be put under the umbrella of a wider "approach" category as an example specimen. Suggestions for such umbrella categories are welcome where appropriate; but with the caveat that classification of technology can get sticky and often depends on one's world view. In my opinion borderline categories such as KnowledgeBase? should perhaps also be included, but with a caveat about fit. After all is said and done, if it better belongs in CategoryDatabase, it can be moved there. But we are still at the brainstorming stage. Note that any given product could potentially fall under 3 different category lists, as explained in the footnotes. That may gum up CategoryDatabase.

How would it "gum up" CategoryDatabase? It's already organised into subcategories. A few more surely wouldn't hurt.

I'm skeptical, but how about we finish this and then see where it fits. I don't like the idea of "category" topics getting too large or complicated. They should only function as first-level menus in my opinion, not content pages.

The existing CategoryDatabase page appears to already cover almost exactly the same territory as this page. What does this page add that CategoryDatabase doesn't have?

It's not as detailed, and the various products would appear in multiple categories if more thorough for reasons already given.

Yes, it sounds fine for various products to appear in multiple categories, and detail already appears on the linked pages. This page is redundant, and unduly flavoured by your editorialising.

I don't see that it covers the same classifications, and lacks synopses. As far as my alleged "editorialising", that's a separate issue than location so that I won't ask for justification of that claim just yet.

It could easily cover the same classifications, and provide short synopses.

It's easier to edit (and debate?) drafts in a short topic than a long one. When it's finished here, THEN we move it there. Deal?

Fine.

Footnotes

[1] One way to view the difference between these is that the "traditional" RDBMS has static tables and static columns (meaning applications typically cannot add or remove tables and columns). DynamicRelational has static tables and dynamic columns, while MultiParadigmDatabase has both dynamic tables and dynamic columns. (It's debatable whether the dynamicness and optional table-ness makes them "non-relational". Also, "column" may not be the best description because the scoping and interpretation is different than in traditional RDBMS).

[2] Perhaps database languages deserve their own catalog page. Essentially, one can consider database implementation strategies, data structure "shape" and interface strategies (this topic), and database languages as more or less 3 independent catalogs. In practice, they each tend to restrain each other to various degrees such that a clean separation is not 100% possible.