MongoDB document uses BSON ( Binary JSON ) to organize data, BSON similar to JSON , JSON is a simple representation of data, contains only 6 data types ( null , boolean, numbers, strings, arrays, and objects) , can not fully meet the needs of a complex business, therefore, the BSON also provide the date, 32 digits, 64 digits, and other types. The following of mongoDB type a brief description:
. 1, null null types indicate null or absence of fields, such as: { "One": null}
2, Boolean Boolean type have the two values, 'to true' and 'to false' , such as: { "One": to true}
3, 32 -bit integer due mongoDB console using JS engine input, JS supports only 64 -bit floating point, so the 32 -bit integer will automatically be escaped;
4, 64 -bit integer
64 -bit integer and 32 -bit integer as in MongoDB when console to be escaped as 64 bit floating point number. Except, if the type of data stored in the database itself either 32 -bit integer or 64 -bit integer, using MongoDB the console acquired, which change documented (integer itself even without modifications, changes only rest of the document), and re-use control Taiwan to write back to the database, its data type will become a 64- bit floating-point.
Except, use the console to view a 64 time-bit integer, it may determine not correct, because some 64 -bit integer can not be accurately represented as a 64 -bit floating-point numbers, and the console are rendered 64 -bit floating-point number.
5, 64 bit floating point MongoDB default type of digital console, such as: { "One": {2.02} "One": 10}
6, a string such as: { "One": "the Hello World"}
7, symbols in MongoDB does not support this type of control panel, it will automatically be escaped as a string;
8, the object id the object id is the only document 12 -bit ID ,
In MongoDB to store documents, you must have a " _id " key, this key can be of any type, if the increase in documentation, do not have this _id key, the system will use the ObjectId automatically generates an object in a distributed environment, different the machine can use a globally unique method to generate the same kind of value that generates rules :
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
Timestamp | machine | PID | counter
Before . 4 bits represent the timestamp, the timestamp in seconds, since the timestamp in the front, can better reflect the time sequence when the data is inserted, to make it easier to query the data, the index is recommended easier.
Although the system will automatically create _id key, but in highly concurrent recommend drivers use to create client applications under the main reason is that although ObjectId can be generated, but the system at the time of generation, or will generate spending, increase the burden on the database.
In highly concurrent distributed environment, only timestamp in seconds and the machine can not distinguish its uniqueness, it is added in behind the PID , i.e. MongoDB process identifier before . 9 characters ensures that the same second different machines in different processes generated ObjectId is unique, two is a counter that is incremented automatically, ensure that the same process to produce the same second ObjectId not the same.
9, the date as a date from the standard epoch ( Year 1 Year ) Number beginning milliseconds beginning, without storage area, such as: { "One": new Date ()} , Note that, if only Date () [no new ] , use the JS type comes with its own time, including time zone, if not the same document at the same time the value of the structure, it may cause inconsistencies in data management;
10, the regular expression document key may comprise a regular expression, regular expression which uses JS syntax expressed as: { "One": / HO / I}
11, the code in the document may contain JS codes such as: { "One": function () {}}
12, the binary data in mongoDB not presented Console
13, the maximum value
14, the minimum
15, an array of document keys can be expressed as an array, but the array type and not strictly within the data member control, members of its type in the array can be completely different, and, in the array can also be nested array;
16, embedded documents embedded document is another document as a key value of this document. So it seems more reasonable reflects the relational data, as we would like to express a blog article and its author, in a relational database, we generally want to create two tables, one for representation blog article (Article This article was) , and the other representing on the blog (author) , and then establish a foreign key relationship to control, and in MongoDB can also be said this
Similarly, we can also be designed to:
Divided into two documents to represent. Better yet it is to be divided into two sets, one article (Article This article was) , one author (author)
Although the document plus subdocument will better reflect the relationship between data, when you query more easily query the information associated with the data, but will cause data redundancy, it is not conducive to data management. Of course, different design approach, depending on usage scenarios need to be determined.
Reproduced in: https: //www.cnblogs.com/Carmack/archive/2011/09/19/2180833.html