Database Reference
In-Depth Information
•
Document
. Instead of taking a business subject and breaking it up into multiple
relational structures, document databases frequently store the business subject in
one structure called a “document.” For example, instead of storing title and author
information in two distinct relational structures, title, author, and other title-related
information can all be stored in a single document called
Title
. This is similar to a
search you would do in a library for a particular topic, where both title and author
information appear together. We have everything to do with the title, including au-
thors and subject, in the same document. It is all in one place, and we do not have
to join to separate places to get everything we need. Document-oriented is much
more application focused as opposed to table oriented, which is more data focused.
MongoDB is a document-based database.
•
Key-value
. Key-value databases allow the application to store its data in only two
columns (“key” and “value”), with more complex information sometimes stored
within the “value” columns such as
Subjects
in our example above. So instead of
doing the work ahead of time to determine whether we have authors or titles, we
can add each type of information (
Title Name
,
Author Name
, etc.) as a key and
then add the value assigned to it. Key-value databases include Dynamo, Cache,
and Project Voldemort.
•
Column-oriented
. Out of the four types of NoSQL databases, column-oriented is
closest to the RDBMS. Both have a similar way of looking at data as rows and val-
ues. The difference, though, is that RDBMSs work with a predefined structure and
simple data types, such as amounts and dates, whereas column-oriented databases,
such as Cassandra, can work with more complex data types including unformatted
text and imagery. This data can also be defined on the fly. So in our author/title
example, we can have a title and the title has an author along with a complex data
type called
Title Characteristics
, which contains the language, format, and sub-
jects, where subjects is another complex data type (an array).
•
Graph
. This kind of database is designed for data whose relations are well repres-
ented as a set of nodes with an undetermined number of connections between these
nodes. Examples where a graph database can work best are social relations (where
nodes are people), public transport links (where nodes could be bus or train sta-
tions), or road maps (where nodes could be street intersections or highway exits).
Often requirements lead to traversing the graph to find the shortest routes, nearest
neighbors, etc., all of which can be complex and time consuming to navigate with a
traditional RDMBS (usually requiring recursion, which is not for the faint of heart
