"Relational" implementations in non-relational databases

Knowledge Dependence:
Before reading the text, you need to understand the concepts and differences between the basic relational database and the non-relational (NoSQL) database, as well as the simple practices of MongoDB (Mongoose).

?

Over the past two or three years, the non-relational database (NoSQL) has become a hot topic in the field of engineering and research, along with the unprecedented heat of big data.

Compared with the traditional relational database, the non-relational database provides a new idea to the data storage from the conception. In practical applications, it tends to be more lightweight, flexible, scalable, and more capable of high-performance, large-volume scenarios.

It is worth mentioning that NoSQL is not the meaning of "No sql", but rather "not just SQL" shorthand.

Although non-relational databases do not have the constraints of many predefined rigid patterns in relational databases, there is always a connection between natural data, so in the database we are bound to abstract the connection between the data.

This article summarizes the common ways in which data relationships can be represented in NoSQL databases in the context of personal practical experience, and combines a practice project to illustrate the example of a node. JS project, using a commonly used document-based database MongoDB (Mongoose).

Here's how:

1. Nesting

Thanks to the flexible data type of the non-relational database, we can directly set a property in Schema A to the "array" type to store all other data objects that have a 1:n relationship with it.

Examples are as follows:

var commentschema = new Schema ({time  : {    type:date,    default:new Date ()  },  content:string}), Var Messageschema = new Schema ({  content:string, time  : {    type:date,    default:new Date ()  },  Comments: {    type: [Commentschema],    default: []  }});

In the example above, a message document may contain many comment documents, so an array is used in the comments property of Messageschema to store all comment of a message.

It is worth noting that here Commentschema does not actually correspond to a data set, it is only used here to help define Messageschema.

This approach is suitable for scenarios where there are frequent queries (less reference queries), strong logical connections (i.e. the need to display a large number of B documents each time a document is displayed), and fewer changes to the B document (after all, a relatively complex nesting operation), compared to the reference method described below.

This approach is also the advantage of NoSQL databases compared to traditional relational databases.

2. References

There is no join-like approach in the traditional relational data in a NoSQL database, so this can make our complex queries relatively difficult, but many packaged database packages offer a lot of convenience.

The reference method can be divided into two types:

Ⅰ. Manual Reference

The manual reference is simple, which is to define a unique (typically _id) attribute in schema B in schema A, and each time you need to query B after query A, you need to manually query the full data of B according to the _ID value defined in a.

The method is simple, no longer an example.

However, the only notable thing in practice is that the B-related attributes defined in a should not have business semantics and will not be altered at all, otherwise when you make changes to the corresponding properties in B, all the A documents referencing this b document need to be updated with the defined reference properties, which is absolutely necessary to avoid! This is also the reason why general references to _id shu?x (typically not changed by business requirements during the life cycle).

Ⅱ. Auto Reference

An automatic reference is a pre-referenced definition with Reference key or Foreign key defined in a similar relational database. At query time, the database can be referenced by a pre-defined reference key to find a document in another collection referenced to.

In some packaged database operation packages, you can implement the function of automatic dereference, that is, any reference key detected automatically to query the corresponding document and then dereference. However, even if it is not an automatic dereference, manual dereference also costs a query, which is why the use of reference queries is more likely. Imagine if the sample in the "nested" method is automatically dereferenced each time, then the 1 queries that are possible in the nested method may need to be n+1 times (N is the length of the comments array in the message).

Examples are as follows:

Defined in User.js:

var userschema = new Schema ({  name: {    type:string,    unique:true  },  password: {    type:string,< C6/>required:true  },  email: {    type:string,    required:true  },  intro: {    type:string ,    required:true  }});

Defined in Msgboard.js:

var messageschema = new Schema ({  user_id: {    type:mongoose. Schema.objectid,    ref: ' User '  },  content:string, time  : {    type:date,    default:new Date ()  }});

Here, we define a reference key user_id reference to Userschema in the _id field in Messageschema. Note: MongoDB will automatically create a unique _id field for the document!

In this way, references are defined at the Schema level. In the case of query, we can decide how to do the operation of dereference according to the characteristics of the package that is used.

In Mongoose, you can use the Populate method. The detailed use method can refer to the Mongoose API documentation, here is just a sample:

Message.find (query)  . Populate (' user_id ', ' name ').  Skip ((page-1) * num_each_page)  . Limit (Num_each_ PAGE). Sort ({time:-1}). EXEC ()  . Then (function (Messages) {    //does something with messages    Console.log ( messages);  }

Here, the messages is queried using the Promise (a type of asynchronous process Control) chain operation, while the skip and limit are used for page flipping.

Focus is on the populate method, where we get the value of the reference to the user document Name field.

For the reference method, because the number of queries in the case of the same amount of data is generally more, it is applicable to the query is not frequent, with a relatively weak logic between the data relationship (not a appears B must appear in the relationship), and use it to define the relationship between the data, but also convenient for various curd data Operation (no nesting or nesting).

For an example of this article in a full project, and other content that builds a Web app with Express4, you can refer to the content and source of the previous article in this blog, focusing on the data model defined under/models and the business code in the/controllers directory.

Note: This article uses the concept of "field" in a relational database in a NoSQL database, actually representing the attributes in a NoSQL database document.

"Relational" implementations in non-relational databases