Comparison between relational database and document database

In the comparison between relational database and document database , We usually consider that each of them has the following advantages ：

• The main argument supporting the document data model is schema flexibility , Because of locality, it will bring better performance , For some applications, it is closer to the data structure used by the application .
• The main argument supporting the relational data model is its support for join operations , A concise expression of many to one and many to many relationships .

1. About the comparison of code conciseness

The first thing to be clear is , We cannot generalize which data model has the simplest application code , This mainly depends on the type of relationship between data items .

• If the application has a document like structure （ It's a one to many relationship tree ）, Then the document model is the most appropriate .
  • Using a relational model in this case will complicate an otherwise simple problem .
  • The document model also has some limitations when describing the document structure , For example, they cannot directly reference nested items in the document . And must use “ user xxx The second item in the position list ”, Such statement description .
  • If the application does not require many to many relationships or many to one relationships , Inadequate support for syndication in document databases is not inherently a problem .
• If the application does use a many to many relationship , Then you should use a relational model .
  • Using the document model is not without a way to handle the connection relationship , For example, send multiple requests , Simulate the join in the application code . But usually doing so makes the system code more complex , Worse performance .
  • Relational models are naturally better at describing many to many relationships .
• For highly correlated data , The relational model is better than the document model , But actually Graph model Perhaps the most natural solution .

2. Schema flexibility in the document model

Most document databases , And... In relational databases JSON Support , No schema is enforced on the data in the document . No schema means that any key value pair can be added to the document , And the client cannot guarantee which fields the document may contain when reading .

The code that reads data in a document database usually adopts a certain structure, so there is an implicit schema , What we call When reading mode （ The structure of the data is implicit , Interpret only when reading ）. In contrast to , The traditional pattern of relationship pattern is called When writing mode （ The mode is displayed , Data assurance data must be written in accordance with ）.

Here is an example , Suppose the full name of the current user is stored in a field , But now I want to store my first name and last name separately ：

• In the document database , We just need to write a new document using the new fields , And deal with reading old documents in the application layer

  if(user && user.name && !user.first_name){
        
      //  Deal with it without  first_name  The old documents of 
      user.first_name = user.name.split(" ")[0];
  }
  

• In a relational database , We usually need to change the table structure

  ALTER TABLE user ADD COLUMN First_name text;
  UPDATE users SET first_name = substring_index(name,' ', 1);
  

  actually , Most relational databases can also perform the above... In a few seconds ALTER sentence . except MySQL In execution ALTER TABLE Copy the current entire table .

  As for the second step UPDATE sentence , Executing this statement on a large table can be slow in any database , Usually you can put first_name Set to default NULL, Fill it on read .

If, for some reason , Not having the same structure , for example ：

• There are many different types of objects , And it is not realistic to store each type of object in its own table .
• The structure of the data is determined by an external system that cannot be controlled , And may change at any time .

In these cases , Patterns can do more damage than they can help .

3. Data locality of query

Documents are usually stored as encoded as JSON、XML Continuous string in the form of . If the application needs to access the entire document frequently （ For example, rendering on a web page ）： Of the document mode Storage Locality Performance advantages . If you follow the relationship pattern , The data is divided into multiple tables , You may need multiple indexes to retrieve all the data , Bring more disks IO, May affect performance .

The locality advantage applies only to scenarios where you need to access most of the document at the same time . Because the database usually loads the entire document , If the application only accesses part of it , It may cause waste . When updating a document , Usually the entire document is rewritten , Only the amount of modification does not change the size of the source document , In situ overwrite update is effective . Therefore, it is generally recommended that The document should be as small as possible and avoid increasing the document size when writing .

4. Integration of document database and relational database

In recent years , Almost all relational database systems support XML. Including yes XML Local modification of documents , stay XML Index and query in documents . In this way, the application can obtain a data model very similar to the document database .

PostgreSQL、MySQL And so on JSON The documentation provides corresponding support .

Document database ,RethinkDB The query interface supports joins similar to relational types , And some of the MongoDB The driver can automatically resolve the reference relationship of the database （ Connect efficiently on the client side ）.

Integrating the two models is a good way for the development of database in the future .