Database Reference
In-Depth Information
Of course, if you are storing only small XML documents and your application doesn't require
document collections, then you are not likely to find any performance benefit in an XML data-
base.
Document-Oriented Databases
In a relational database, data is stored in terms of tables, requiring data that might otherwise
be repeated to be “broken apart” in order to use relational keys. You then can employ complex
queries written to pull your relational data back together for a single query result that captures
the data in a two-dimensional grid of rows and columns.
There are several advantages to document-oriented databases in general:
▪ The basic unit of storage in a document database is a complete document itself. A document
can store any number of fields of any length, and each field can store multiple values. This
differs from a relational database, which requires all fields to be present for every record.
▪ In a document-oriented database, you don't need to store “empty” fields for which you have
no data, as is required in RDBMS. This can save space in the database.
▪ They are very free-form in that they do not require a schema.
▪ Security can be assigned at the individual document level.
▪ They typically include full-text search capabilities. This is sometimes provided as a special
feature of RDBMS and is common in XML databases.
So what is meant by a “document”? It could be text, written and stored as JSON (see ); it could
be XML, though there is a separate discussion around that specialized form of document data-
base; it could be a YAML document (most JSON documents can be parsed by a YAML parser);
and it could also be a different format, as there are a variety of alternatives. The technical im-
plementations from one document database to another are not the same. For instance, CouchDB
stores data as JSON, and Lotus Notes, which has been around much longer, uses its own internal
format.
