为我的节点应用程序select正确的数据库
我是新的节点js＆我需要build议为我的节点应用程序select数据库。
比方说，我的名单上有几个游戏（以千计）。 数组应该看起来像这样：
{ "Football": { "John": [{ "age": "1", "weight": "2", "height": "3", }], "Smith": [{ "age": "11", "weight": "22", "height": "33", }], ... }, "Golf": { "Ricky": [{ "age": "4", "weight": "5", "height": "6", }], "Jonathan": [{ "age": "44", "weight": "55", "height": "66", }], ... }, ... /* Thousand more to go */ ... } 现在，随着应用程序，我将通过他们的名字查询游戏。 我想将这个数组结构存储到节点的数据库中。 我应该去哪一个？ 哪一个易于pipe理/更新和更快？ 我应该使用NoSQL数据库吗？
So i made a little research here it is Mongo vs MySql ——————————o—————————— References: —> 'https://www.mongodb.com/compare/mongodb-mysql' —> 'https://www.upguard.com/articles/mysql-vs-mongodb' —> 'https://www.techopedia.com/6/28832/enterprise/databases/introduction-to-databases/6' —> 'https://docs.mongodb.com/manual/reference/sql-comparison/' ——————————o—————————— MySql √ MySQL is a popular open-source relational database management system (RDBMS) that is developed, distributed and supported by Oracle Corporation. Like other relational systems, MySQL stores data in tables and uses structured query language (SQL) for database access. In MySQL, you pre-define your database schema based on your requirements and set up rules to govern the relationships between fields in your tables. In MySQL, related information may be stored in separate tables, but associated through the use of joins. In this way, data duplication is minimized. √ The basic MySQL system ships with no GUI tools, only a set of CLI's. There is an official set of front-end tools called MySQL Workbench, freely available from Oracle. MySQL runs on all major operating systems —>When MySql is a Better Choice: √ Applications that require complex, multi-row transactions (eg, a double-entry bookkeeping system) would be good example. A concrete example would be the booking engine behind a travel reservation system, which also typically involves complex transactions. √ MySQL is mostly used in to store data for web applications but that's not to say MySQL cannot support large enterprise databases ——————————o—————————— MongoDB vs MySql —> Terminology and Concepts: Ø MySql: Table, Row, Column, Joins Ø MongoDB: Collection, Document, Field, Embedded documents and Linking —> Features: Ø MySql: Typed Data, Field Updates, Complex Transactions, Auditing Ø MongoDB: Rich Data Model, Dynamic Scheme, Typed Data, Data Locality, Field Updates, *Easy For Programmers*, Auditing, Auto Sharing. ——————————o—————————— MongoDB √ MongoDB is a well-known open source non-relational database. It employs the concept of key-value pairs, here called a document store. In MongoDB document stores are created and stored as BSON files, which are really a modified version of JSON files. √ Mongo offers very good performance for situations containing very high write loads, but where data integrity isn't a pressing concern; a good example are the comments sections of large, busy websites like Craigslist or The New York Times – by the way, these aren't theoretical by the way: both of these use MongoDB. √ One major limitation of MongoDB is that unlike the relational MySQL, it does not offer an easy way to join tables. It has an inelegant solution to this: multi-dimensional data types in which you can embed one document store inside another. So for instance you can embed the customer account document consisting of the {“Customer_account_type: Current”, “Customer_balance: $28,400”} document into the customer data document {“Customer name: Andrew Jones, “Customer_gender: M”} and in this way retrieve the data about both the customer and his bank balance. As mentioned, it's inelegant and awkward but it works. —> Common Use Cases: √ MongoDB is a general purpose database that is used for a variety of use cases. The most common use cases for MongoDB include Single View, *Internet of Things*, *Mobile*, *Real Time Analytics*, Personalization, Catalog, and Content Management ——————————o—————————— Relational Data Bases √ Relational databases are excellent for representing and working with sets of data, similar to finding the region covered by intersection points in a Venn diagram. For instance, in a commercial bank's application, it is simplicity itself to create a SQL query to extract, say, the names and contacts of all female customers, with a current-account balance over $100,000, who have taken out a loan in your bank within the last 2 years. SQL can easily allow you to get that accurate using the famous SELECT statement. The tight rules governing relational database structure mean that it is easy to ensure data integrity and security. √ However, what SQL and relational databases are not good at is scaling. Because of the necessary table and database structure in relational databases, they really only scale well vertically within a single server - by increasing memory and CPU, using faster disks, etc. But they don't scale well horizontally by adding more servers to share the load, ie distributed computing. This is where the relational models own strengths turn into weaknesses. √ They have three main advantages: 1. A simple way of representing data/ business models 2. An easy-to-use language to retrieve and query that data (SQL) 3. Bulletproof data integrity and security built right into the database without having to rely on application rules and logic. √ Are like trains: Better for moving large quantities of goods ——————————o—————————— Non-Relational Data Bases √ One of their defining characteristics is that they are able to take scale very well across several servers and reap the advantages of distributed computing. With the advent of fast Internet connections, these servers may be in sync even over widely dispersed geographical locations (Google!). One way of achieving this is by storing data in key-value pairs, rather than the traditional table. A key-value pair is a combination of a data item and its related value. √in NoSQL databases, the data field and the value for that field are stored together as one record. This makes data retrieval much faster and enables , but also introduces problems with data integrity. A relational table, on the other hand, would store the same customer data as a set of distinct tables, one containing the customer bio-data (name, date of birth, gender, social security number and so on), another containing customer balances (account type, balance) and so on. √ Are like cars: Better for smaller quantities of goods ——————————o——————————
我希望这可以帮助你一点点，也为你提供更多信息。 正如我所知，mongo不保证在使用时不会丢失数据，只保证快速的数据stream。
RDBMS（SQL DB）vs NoSQL
SQL DB
- 维护数据之间的关系
- 固定或预定义的模式
- 数据存储在行和列中
- 垂直可伸缩（在硬件上会受到限制，比如你不能继续向服务器机器中添加RAM），机器有多less内存可以增加的限制。
- 数据量巨大时，存储和检索速度相对较慢。
NoSQL DB – 数据之间没有关系 – dynamic模式 – 数据存储为文档，graphics，键值等（ https://en.wikipedia.org/wiki/NoSQL ） – 水平可伸缩通过添加更多的服务器来完成 – 存储和检索速度更快
哪一个易于pipe理/更新和更快
如果您想更快地pipe理/更新，NoSQL将最适合您的模式和数据量
但是，如果可以考虑重构您的模式，通过为用户制作Unique文档并将其添加到其中。 这将有助于您检索数据。
重组后的示例数据
{ "id": 1, "name": "John", "age": "1", "weight": "2", "height": "3", "games": [{ "Football"}] }