Hi,
Document base database. From the name you can get that it has something to do with a database and document. Initially i thought it as database with proper documentation. But it turned out to be database which uses documents to store the data. They can be opened and read like any other file.
Many people who have been using RDBMS like mysql will find it difficult to switch on to this type. Because this is an entirely new concept where you need to unlearn things. We need to think apart from normalization and relations.So lets get started.
Why Document-based:
Well each new concept has a reason behind it. And the reason for the document-based is to overcome the rigidity of the RDBMS. By rigid we mean the strict rules in terms of schema.DBD also prevent joining tables as the details which need to be retrieved by joining multiple tables can be provided within the same document.
There is no schema in DBD. Each document can contain its own set of attributes which can vary from one document to another(even though it is preferred to have similar attributes in the document ).
Comparing RDBMS and DBD using example:
For example (in MongoDB):
db.users.({name:'prem', likes['facebook','twitter'] });
The above statements adds two documents to the collection users with names "prem" and "praveen". These both documents have two different attributes i.e, likes and cars. Thus we can add each document different data types in runtime. Sounds good right....
If we need the same thing to be done using MySQL the schema would be,
create table users (name varchar(10),likes1 varchar,likes1 varchar,cars1
Then for prem there would be two NULL columns in cars1 and cars2. The same would be case for praveen in the likes column. If we need to increase the number of cars owned by praveen we need to alter the entire table in RDBMS. But in DBD only the particular document will be affected.
Consider a query where you need to "find number of people who like facebook". The query can be done in DBD too. But searching each attribute of document to address the query is not a proper way. So you may need to rethink the structure of the documents.
Storage in DBD:
Well another advantage of DBD is that the documents are in text files. So the processing of these documents are extremely fast compared to the relational database.Here the Documents are analogous to records and the collections are analogous to the tables.
Searching with JASON:
Each documents are addressed by a key-value pair. For each document a unique id is generated. Thus search for a document is faster. DBD allows API's such as REST using JSON which is pretty much faster than RDBMS( JDBC , ODBC ). Each document is a object of JASON. In the previous example the two user objects 'prem' and 'praveen' are JSON. For good knowledge on JSON refer http://www.json.org/.
The use of JASON makes the DBD to support javascript very much. They also form effective means of communication between server and client as the message transfered will be in the form of JASON rather than XML documents.
Primarily the DBD came into use to manage huge amounts of data. The DBD allows writing very fast and hence they are used in write intensive application. Even in reads it is better to use rather than RDBMS.
Transactions:
But the problem in this is that we cannot go for transactions in DBD. Even though there are facilities to support transactions these days. DBD are not preferred for transactions. There is no possibility to go for locks in DBD.
There can be situations when you need to split the collection into two with a common value to link the two collections(foreign key in RDBMS). Even though we can implement the above scenario using DBD it is not advisable.
Document base database. From the name you can get that it has something to do with a database and document. Initially i thought it as database with proper documentation. But it turned out to be database which uses documents to store the data. They can be opened and read like any other file.
Many people who have been using RDBMS like mysql will find it difficult to switch on to this type. Because this is an entirely new concept where you need to unlearn things. We need to think apart from normalization and relations.So lets get started.
Why Document-based:
Well each new concept has a reason behind it. And the reason for the document-based is to overcome the rigidity of the RDBMS. By rigid we mean the strict rules in terms of schema.DBD also prevent joining tables as the details which need to be retrieved by joining multiple tables can be provided within the same document.
There is no schema in DBD. Each document can contain its own set of attributes which can vary from one document to another(even though it is preferred to have similar attributes in the document ).
Comparing RDBMS and DBD using example:
For example (in MongoDB):
db.users.({name:'prem', likes['facebook','twitter'] });
db.users.({name:'praveen',cars['ducati','ferrari']});
The above statements adds two documents to the collection users with names "prem" and "praveen". These both documents have two different attributes i.e, likes and cars. Thus we can add each document different data types in runtime. Sounds good right....
If we need the same thing to be done using MySQL the schema would be,
create table users (name varchar(10),likes1 varchar,likes1 varchar,cars1
varchar, cars2 varchar);
Then for prem there would be two NULL columns in cars1 and cars2. The same would be case for praveen in the likes column. If we need to increase the number of cars owned by praveen we need to alter the entire table in RDBMS. But in DBD only the particular document will be affected.
Consider a query where you need to "find number of people who like facebook". The query can be done in DBD too. But searching each attribute of document to address the query is not a proper way. So you may need to rethink the structure of the documents.
Storage in DBD:
Well another advantage of DBD is that the documents are in text files. So the processing of these documents are extremely fast compared to the relational database.Here the Documents are analogous to records and the collections are analogous to the tables.
Searching with JASON:
Each documents are addressed by a key-value pair. For each document a unique id is generated. Thus search for a document is faster. DBD allows API's such as REST using JSON which is pretty much faster than RDBMS( JDBC , ODBC ). Each document is a object of JASON. In the previous example the two user objects 'prem' and 'praveen' are JSON. For good knowledge on JSON refer http://www.json.org/.
The use of JASON makes the DBD to support javascript very much. They also form effective means of communication between server and client as the message transfered will be in the form of JASON rather than XML documents.
Primarily the DBD came into use to manage huge amounts of data. The DBD allows writing very fast and hence they are used in write intensive application. Even in reads it is better to use rather than RDBMS.
Transactions:
But the problem in this is that we cannot go for transactions in DBD. Even though there are facilities to support transactions these days. DBD are not preferred for transactions. There is no possibility to go for locks in DBD.
There can be situations when you need to split the collection into two with a common value to link the two collections(foreign key in RDBMS). Even though we can implement the above scenario using DBD it is not advisable.
No comments:
Post a Comment