There seems to be some recent buzz about "dynamic" databases that are allegedly more flexible than "traditional" RDBMS.  The common thread seems to be that they are more dynamic than "traditional" RDBMS but are still based on some variation on "records", predicates, and are not generally hierarchical or network-oriented (pointer-centric). With all the ideas floating around, the vocabulary for them is getting messy. Here's a starting list of feature combinations they come with or omit.

Common to all:

* Have some concept of "record", be it a tuple or map. That is, a list, map, bag, or set of attribute/value pairs.
* Uses predicates as the primary access filtering/searching mechanism. (This separates them from a NetworkDatabase, which primarily uses pointers or navigation verbs (up, down, next, previous, etc.) to navigate.)
* Generally not hierarchical, at least not as the primary org feature. (This would exclude an EssExpression-based DB, for example.)

Variations among:

* Uniqueness per record (required, not required, circumstantial combo's, etc.)
* Hard-versus-soft "schema" - Dynamic-ness of the "record" layout. Can new attributes be added willy-nilly at the record level, require a formal change request to a "master", or something in-between.
* Tables - Does the DB formally support tables, or are they informally "created" using attributes (table="foo").
* Uniqueness of attributes ''within'' a record. For example, is "carID=7654,color='red',color='blue'" allowed.
* Auto-generated "record number". Is it required (automatic), optional, or not available.
* Some have bits of NavigationalDatabase characteristics to them, but are not heavily geared toward them.

Ideally, one would have a choice of which of these features to have switched on or off, similar to InstantLanguageForm. However, as is often the case, performance needs may trump quantity of choices and/or combinations.

--top

''Excluding the stuff you generate (MultiParadigmDatabase, DynamicRelational), I'd be interested in seeing some of this 'recent buzz' you claim to exist.''

* http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php

* http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/09/03/24/12TC-databases_1.html

* http://blog.oskarsson.nu/2009/06/nosql-debrief.html

* http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9135086

It's now generally known as the "NoSql movement" (Oct. 2010)

----
Do you mean ObjectDatabase? http://en.wikipedia.org/wiki/Object_database -AnonymousDonor

''No, that's not what the original author means.''

''"Alternative" database models have long been a popular topic for MSc student theses, breathless jounalism that proclaims the RelationalModel dead, and the like.  None have any achieved any market popularity, at least compared to conventional implementations of the RelationalModel and SqlLanguage DBMSes, and indeed many are simply variations on -- or slight deviations from -- ways to implement the RelationalModel.  Much of what are considered characteristics of the RelationalModel -- such as static schemas (or not), provision of auto-generated record numbers (or not), etc. -- are matters of convention rather than requirement.''

OODBMS generally don't qualify because they are mostly navigational in nature, not predicate-based (see 2nd "rule"). Predicate navigation is generally "anti-encapsulation". Encapsulation generally implies that you go through the "parent" object or component to get to sub-components. Thus, it's path-based. Some OODBMS may have a predicate option, but it could be argued that this makes it "less OO", a hybrid database. '''The whole big-picture database classification thing may be mostly a UsefulLie''', because in practice things can and do often have a smattering of features from different paradigms and philosophies. --top

--------
http://en.wikipedia.org/wiki/Graph_database
--------
See also: TupleSpace, MultiParadigmDatabase, DynamicRelational, NoSql
----
CategoryDatabase