Graph databases are similar, but add another layer, the relationship, which allows them to link documents for rapid traversal.
The difference[contradictory] lies in the way the data is processed; in a key-value store, the data is considered to be inherently opaque to the database, whereas a document-oriented system relies on internal structure in the document in order to extract metadata that the database engine uses for further optimization.
Although the difference is often negligible due to tools in the systems,[a] conceptually the document-store is designed to offer a richer experience with modern programming techniques.
Likewise, the specific set of indexing options and configuration that are available vary greatly by implementation.
They may offer search systems similar to those of a document store, but may have less understanding about the organization of the content.
This allows them to search on those types of data, for instance, all phone numbers containing 555, which would ignore the zip code 55555.
A document-oriented database provides APIs or a query/update language that exposes the ability to query or update based on the internal structure in the document.
This difference may be minor for users that do not need richer query, retrieval, or editing APIs that are typically provided by document databases.
Some search engine (aka information retrieval) systems like Apache Solr and Elasticsearch provide enough of the core operations on documents to fit the definition of a document-oriented database.
The PHONE_NUMBER table also contains a foreign key column, "CONTACT_ID", which holds the unique ID number assigned to the contact when it was created.
That entry is accessed through its key, which allows the database to retrieve and return the document to the application.
A key difference between the document-oriented and relational models is that the data formats are not predefined in the document case.
Most also offer the ability to add additional metadata outside of the content of the document itself, for instance, tagging entries as being part of an address book, which allows the programmer to retrieve related types of information, like "all the address book entries".
In the classic normalized relational model, objects in the database are represented as separate rows of data with no inherent structure beyond that given to them as they are retrieved.