Many NoSQL databases share one thing in common, that is, they have no mode. To store data in a relational database, you must first define a "schema", that is, to explain to the database in a predefined structure: What tables are required and what columns are in the table, the type of data that each column stores. You must define the mode before you can store data. In contrast,
Many NoSQL databases share one thing in common, that is, they have no mode. To store data in a relational database, you must first define a "schema", that is, to explain to the database in a predefined structure: What tables are required and what columns are in the table, the type of data that each column stores. You must define the mode before you can store data. In contrast,
Many NoSQL databases share one thing in common, that is, they have no mode. To store data in a relational database, you must first define the "Mode", that is, to explain to the database in a predefined structure: What tables are required and what columns are in the table, the type of data that each column stores. You must define the mode before you can store data.
In contrast, NoSQL databases are more casual in terms of data storage. "Key-value Database" can store any data under a "key" name. This is also true for "Document Database" because it has no restrictions on the structure of the stored documents. In a column Family database, any column can store data at will. You can add edges in graph databases or add attributes to nodes and edges at will.
Advocates of the schema-free database enjoy the freedom and flexibility it brings. If the mode is used, you must specify the data you want to store in advance, but this is more difficult. After getting rid of the constraints of the mode, we can easily store the required data, so we can easily modify the original data storage method based on the progress of the project. Once new things are discovered, you just need to add them to the database. In addition, if you find that something is useless, you can stop storing it. If a column is deleted from a relational database in usage mode, you may have to worry about whether this operation will cause the loss of old data.
In addition to the differences in data changes, the schema-free database also makes it easier to process nonuniform data ), that is, the data in which each record has a set of fields. "Mode" forcibly unifies the Data Types of each row in the table. If the data types of different rows are different, it is awkward to do so. You can either use a lot of columns to store the data, and fill in the field values that are not used as null (this becomes a "sparse table", sparse table ), you must use a column type that is meaningless like custom column 4. The schema-free table is not so troublesome. Every record only needs to contain the data it needs, so you don't have to worry about the above problems.
The schema-free database is very attractive and can indeed avoid many troubles when using fixed-schemadatabase. However, it also has some problems. If the data is stored to display it as a simple report in the format of "field name: field value" (fieldName: value), the "Mode" is indeed an obstacle.
However, the task we usually need to complete when processing data does not end here, and the data processing program needs to know that the field for storing the bill address is billingAddress rather than addressForBilling, the quality field should contain the integer "5" instead of the word "five ".
When writing a data access program, you must face a key problem: although sometimes inconvenient, the program usually depends on some form of "implicit schema ). Unless you only need to execute the following simple logic.
// pseudo codeforeach (Record r in records) { foreach (Field f in r.fields) { print (f.name, f.value) }}
Otherwise, the program must assume that some specific field names exist in the table. These fields contain data of certain significance and also assume that the field contains some type of data. Programs are different from humans. They cannot infer immediately after they see "qty" that it has the same meaning as "quality", at least when we don't specifically write specific processing code for it, it does not work. Therefore, no matter what the Database "NO mode" is, there will always be "implicit mode ". It refers to a series of assumptions about the data structure when writing data operation code.
Implicit mode in application code may cause some problems. It means that to understand the data stored in the database, you must thoroughly study the application code. If the code structure is very good, You can infer the data mode based on it, but this is not guaranteed, because it depends entirely on whether the application code is clear. In addition, the schema-free database cannot perceive the schema, so it cannot use the schema to improve the efficiency of data storage and acquisition, and it cannot verify the data on its own, to prevent multiple applications from operating their data in an inconsistent manner.
The above problem is the reason why relational databases adopt the fixed mode. In the past, databases used the fixed data mode, which is precisely Based on this consideration. "Mode" has its value, while NoSQL database abandon mode is a very surprising decision.
In essence, a schema-free database is the application code that accesses its data. If different programs created by multiple developers need to access the same database, it will be troublesome. There are several ways to alleviate this problem. One way is to encapsulate all database interaction operations into independent applications and integrate them with other applications through Web Services. Currently, many developers integrate applications through Web Services. This method is very suitable for such development scenarios. Another way is to clearly divide different regions for different applications in aggregation. In a document database, documents can be divided into different sections (p). In a column Family database, different column families can be assigned to different applications.
While NoSQL supporters often criticize relational databases, saying they must predefine the model and its model is not flexible, this is not the case. The relational database mode can be modified through standard SQL commands at any time.
If necessary, you can immediately add new columns to store "inconsistent data types ". We only seldom encounter this situation, but if we do, this method can fully cope with it. However, in most cases, if you find that the data types to be stored are not uniform, you should choose a schema-less database.
The schema change of a database has been profoundly affected by a schema-less database, especially when data in different storage formats is used. The relational database model can also be changed in a controllable way, but its application scope is not as wide as ideal. Likewise, you can control the data storage mode in a schema-free database to make it easier to access new and old data. In addition, the flexibility of "no mode" is limited to internal aggregation. If the aggregation boundary is changed, the data migration work is as complicated as that of relational databases.
Http://www.fix.com.cn/news/yenaxinwen/20140303/3226.html
