10
I have seen that there are numerous object-oriented, aspect-oriented, class-oriented and various other terminologies.
But what I’ve seen recently is document-oriented, as stated in Mongodb’s description:
Mongodb (humongous, "gigantic") is a high-performance, open-source application with no schematics, document-oriented.
8
What it means document-oriented?
In the context of Mongodb means that data is stored in complex object format, as in the example below:
{
title: "MongoDB: The Definitive Guide",
author: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
publisher: {
name: "O'Reilly Media",
founded: 1980,
location: "CA"
}
}
The next two darlings are equivalents:
SELECT * FROM BOOKS WHERE pages >= 216; // Transact-SQL
and
db.getCollection("BOOKS").find({pages: { $gte: 216 } }) // BSON
Note that the object follows the JSON notation. This is by default: O Mongodb uses JSON for data exchange, and BSON - a binary, extended version of JSON - to allow descriptions of data types and logical operators.
What are the main qualities/differences of this paradigm?
Traditional DBMS tables are two-dimensional structures (columns x rows). This means that you need to decompose a complex object into nested structures (e.g.. NotaFiscalCabecalho, NotaFiscalItens) before storage - and conversely collect records from multiple tables to recompose the object.
With a database that stores complex objects, this step is unnecessary.
Is this term only applicable to the database? If not, where else can it be used?
I would say not. Any structure that works with serialization of complex objects - disk storage of JSON files, for example - can be considered a document structure (according to the definition of Mongodb).
What about performance (response time, expansion capacity) vs a relational? Any difference when storing objects?
You talked about serialization and deserialization of complex objects, I remembered an architectural discussion about information timing in a sales force system, whether we would synchronize using documents or whether it would be by lines.
@leonardopessoa depends on the application. And it depends a lot. Mongodb is not the silver bullet, but also should not be taken out of the conversation forever. In general, information that is stored hierarchically is better represented as documents, but if the dependency graph is too complex and less tree, the relational model works too well
@leonardopessoa If your application deals with complex objects then there is significant savings in your process, since you can ignore decomposition/composition routines. As for response time, my personal experience indicates that differences are irrelevant to simple structures, and considerable if you use structural research.
@Jeffersonquesado There are operands that allow patching (addition/partial edition) of documents, which is useful in this case.
@Onosendai liked this idea of patch. Maybe get out in the third version of the sync? :-)
Browser other questions tagged terminology paradigms
You are not signed in. Login or sign up in order to post.
It is to counter relational database. It uses the concept of document, not linked tables.
– Jefferson Quesado
If I’m not mistaken, Couchbase is also documentary
– Jefferson Quesado