A small MFC connects to the MySQL database to log in to the instance via ODBC
File: n459.com/file/25127180-479633004 Access password: 551685
The following are irrelevant:
-------------------------------------------Dividing line----- ----------------------------------------
In fact, I wanted to write articles related to distributed databases very early on. This is what I am studying now, and it is also something I am very interested in. But when it comes to distributed databases, many relevant technical details are involved. When the relevant details are clearly written, more than a dozen articles have passed XD. So if you want to understand the technical details of B/B+ tree, LSMT, CAP, etc., you can read the previous article. Today we will talk about the concept of NoSQL.
The general meaning of
noSQL NoSQL is very popular now. Nine out of ten of the resumes I have read are familiar with noSQL, but few people can explain the details behind noSQL, even what the no in noSQL means Many people make a mistake. This no does not mean not, but an abbreviation of not only. I have to say that this acronym is really cheating, no one should be able to guess what it means literally. And even if it is interpreted as not only SQL, it's still a bit clouded, and it is not very accurate to get its point.
Because the English word for SQL is structured query language, which means structured query language. It can be considered a special programming language, but what does "not just SQL" mean? It's really puzzling, so we can't understand it literally, we need to understand it from actual application scenarios.
SQL application scenarios are relational databases, such as the commonly used Oracle and MySQL, which are relational databases. When we understand the database, we often start with the structure of the table to understand. What is stored in the database is a sheet of tables, a table is composed of rows of data, and each row of data has a fixed field. I think everyone should be very familiar with this point. Even if you haven't learned the database or have returned to the teacher like me, you should have more or less impression.
But why is it called a relational database instead of a table structure database?
Because in the database, the relationship is more important than the table structure. The table structure is just a form, and the core design concept in the database is actually a relationship. This is why we all need to start from the ER diagram when we learn the database, instead of talking about the database usage method or the details of the SQL language. If you don't understand the meaning of this sentence, it doesn't matter, let's put it aside first, and finally return to this topic.
The question is, we know that the commonly used SQL database is a relational database, so what is the database represented by noSQL?
I have seen at least two statements about the concept of noSQL, one is non-relational database, and the other is document database. When I personally understand it, I feel that these two statements are not perfect, but in comparison, the second statement is obviously better, because the first statement does not provide us with any information. The document in the document database is not the meaning of a document that we usually understand, but refers to the structure and core logic of data storage.
A vivid example
Like most technical concepts, noSQL is relatively obscure, and it is difficult to describe it clearly in language. So I decided to cite a lively example that everyone is familiar with-the omnipotent X treasure.
The following is a picture of the product details page in X treasure (select it at will, not an advertisement, if there is a coincidence, please pay the promotion fee):
Everyone should be familiar with this picture. We must have seen it many times in our usual online shopping activities. It looks a bit dazzling. We abstracted and condensed the above content and drew it into a sketch. It looks like this (it is a bit sloppy):
That is to say, we roughly divide the content displayed on a product detail page into three parts, one part is the product image, the other part is the product description, and the other part is the user's comment. The design of the product detail pages of the major e-commerce companies are similar, and some details may be different, but the overall modules are not much different.
In order to simplify the problem, we assume that the product detail page needs to associate three tables of image information, text description, and user comments. In fact, this division is not scientific. For example, the text description and the product map can be stored in the table of the product detail page. For example, in addition to this information, there are also product sales information, such as inventory, prices, current offers, activities, etc. But these have little to do with our final conclusions, and can be simply understood as such.
According to the above division method, we should look up the picture, text and comment information of the product according to the itemId, which is of course no problem on the surface. But in fact this is problematic. The problem is that these data are not a one-to-one relationship, but a one-to-many relationship.
For example, there are often more than one picture displayed on the head, and the text may have more than one paragraph, and the same user may have more than one comment. How to solve this problem?
You may come up with a way. It's not difficult. We add the itemId field to the img, text and comment tables, and associate it with itemId when we query, isn't it OK?
Of course it is possible to do so. Assuming that you are the programmer responsible for this project, you have made this update, and after the successful launch, the product has brought you a new requirement. She said that I want to display pictures in both the text introduction and user comments. Although the system was not designed like this at the beginning, I don't care, I just need it, immediately.
You rolled your eyes for a while, calmed down for a long time, and after thinking about it, you finally thought of two options. The first option is to add a field to the current picture table to determine whether the picture is used for detail page display or comment. Page display, the text introduction to be added later and the picture in the comment page still exist on this table. The second plan is to rebuild a new table, dedicated to the special table, responsible for storing the pictures of the comment page and the description page.
The advantage of the first solution is that we don't need to build a new table, which avoids table redundancy. If every requirement needs to build a new table, it is obviously a huge burden for subsequent maintenance. But its disadvantage is that we need to modify all the previous data in batches, because there is no source field in the previous data. Of course, you can also use id to distinguish without this field, but this is not in compliance with the specification, and it will inevitably leave security risks.
The advantage of the second solution is simple operation, no need to change the previous data, and less security risk, but the problem is that it needs to occupy new resources and the utilization rate is low, because some details page pictures and top pictures can be shared. If you store them separately, you need to store multiple copies.
These two schemes have their own advantages and disadvantages, and both seem to be good, but the pitfall is that they all have a common disadvantage, that is, they will increase the complexity of the current system and query. One is to increase the fields passed in when querying, and the other is to initiate additional queries. Whichever one is selected, the system will become more and more complicated. Later, when a user request comes, dozens of linkage requests will be driven to assemble complete data. Now the product introduction part of the latest version of X treasure's detail page is always displayed with pictures, without text, maybe it is driven by this problem behind it.
Let’s review this example. Why our query is so complicated is actually related to the core concept of the database. The data stored in the relational database is the relationship. In this problem, we need to query the relationship between the product and the picture, the relationship between the product and the description, the relationship between the product and the review, the relationship between the review and the picture, and so on. In other words, the page we finally see is actually the result of this series of relationships. Behind each query is a process of relationship decomposition and then merging, so it will be very complicated.
Document database
We have just looked at the problems of relational database in the e-commerce scenario, let's look at the performance of document database in the same scenario.
Unlike relational databases, the core of document database storage is documents. Of course, the document here does not refer to the document in our usual sense, but the data in json or xml format. Among the current noSQL databases, json data is more commonly used. We also use the example of the details page just now to see how this data is stored in the noSQL database:
{ "ItemID": 123, "itemName": "iPad Pro", "topImgs": ["imgs1.path", "imgs2.path"], "desc": [{"text": "iPad Pro", " img": “”}, {“text”: “2020 new version”, “img”: “imgs1.path”}], “comments”: [{“userName”: “chengzhi”, “comment”: “good product", "imgs": ["imgs3.path", "img4.path"]}] } You see, in the document database, the complex just now requires multiple queries and a series of processing before it can be screwed together The data can be obtained by one query through itemID.
Simply speaking, it is much more convenient than relational databases, but it is not without its shortcomings. One of the big problems is that we store all the data directly in the document, which on the one hand causes data redundancy, on the other hand, it also limits the scalability. For example, similar products under the same merchant cannot share pictures, but must store multiple copies, which causes a waste of space. For another example, suppose we want to support users to modify the past comments before it will be very troublesome, because we have to find all the documents that store user comments to modify (assuming that user comments are also used in other scenarios), which is often cross-system and Very inconvenient.
This problem is not unsolvable. For example, we can replace the specific data stored in the document with an id. For example, the specific picture and comment information are no longer stored in the comment, but the id of a comment is stored, and then associated when using it. . Due to the structure of the document database, the support for association is not good, and we often need to manually query based on the ID to simulate the connection, which will also bring additional overhead.
Another small flaw is that the path for us to access data in the document database has become longer. For example, add we want to get the first picture in the second article of the product review. We need to write item['comments'][1]['imgs'][0], and in relational databases, since pictures are directly queried through relations, it is more convenient.
In addition to these, the development years of noSQL databases are much shorter than those of more mature relational databases such as MySQL, so the supported features are relatively small.
Summary
Through an example, we vividly compared the difference between relational databases and noSQL databases. Let's go back to the question at the beginning of the article. Why do we need to start with the ER diagram when learning the database, instead of directly learning the principle of the database and its use?
I think after understanding the above example, it should be much easier to look at this problem. Because the core logic of a relational database is to store relationships, usage specifications, various techniques and features are essentially developed around this core. If we use the database without getting to this layer, it is easy to go astray. This is how many unthinkable operations come from. For example, someone stores the code of the front-end page in the database, such as concatenating the id into a string to store multiple Value and so on. This also shows that the content of the classic textbook is not nonsense, and each chapter has its intended role. Therefore, when we feel that some content is useless, it may not be that the textbook is wrong, but we have not understood it properly.