我是节点js＆amp;的新手。我需要为我的节点应用程序选择数据库的建议。
说，我的列表中有多个游戏（数千个）。数组看起来像这样：
{
"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 */ ...
}
现在，借助应用程序，我将以他们的名字查询游戏。我想将此数组结构存储到节点的数据库中。我应该去哪一个？哪一个易于管理/更新＆amp;更快？我应该使用NoSQL数据库吗？
答案 0 :(得分：1)
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 (e.g., 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, i.e. 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不保证在使用时不会丢失数据，只保证快速数据流。
答案 1 :(得分：0)
RDBMS（SQL DB）与NoSQL
SQL DB
NoSQL DB - 数据之间没有保持关系 - 动态架构 - 数据存储为文档，图形，键值等（https://en.wikipedia.org/wiki/NoSQL） - 水平可扩展，可以通过添加更多服务器来完成 - 存储和检索更快
哪一个易于管理/更新＆amp;更快
如果您想以更快的方式管理/更新，NoSQL最适合您的架构和数据量
但是，如果可以考虑重构您的架构，可以为用户制作唯一文档并将游戏添加到其中。这个会 帮助您检索数据。
重组后的样本数据
{ "id": 1,
"name": "John",
"age": "1",
"weight": "2",
"height": "3",
"games": [{ "Football"}]
}