简体繁体 English

将关系数据库转换为非关系数据库的最佳实践？

[英]Best practices for transforming a relational database to a non relational?

原文 2020-06-12 11:03:36 8 2 mysql/ database/ mongodb/ mongoose/ migration

I have a MySQL Database and I need to create a Mongo Database (I don't care about keeping any data).我有一个 MySQL 数据库，我需要创建一个 Mongo 数据库（我不关心保留任何数据）。

So are there any good practices for designing the structure (mongoose.Schema) based on the relational tables of MySQL?那么根据MySQL的关系表来设计结构（mongoose.Schema）有什么好的做法吗？

For example, the SQL has a table users and a table courses with relation 1:n , should I also create two collections in MongoDB or would it be better to create a new field courses: [] inside user document and create only the user collection ?例如，SQL 有一个表users和一个表courses关系为1:n ，我是否也应该在 MongoDB 中创建两个 collections 或创建一个新的user collection user document字段courses: [] ?

2 个解决方案

The schema definition should be driven by the use cases of the application.模式定义应该由应用程序的用例驱动。

Under which conditions is data accessed and modified.在什么条件下访问和修改数据。 Which is the leading entity.哪个是主导实体。

eg When a user is loaded do you always also want to know the courses of the user?例如，当一个用户被加载时，您是否也总是想知道该用户的课程？ This would be an argument for embedding.这将是嵌入的论据。

Can you update courses without knowing all of its users, eg update the name of a course?您能否在不知道所有用户的情况下更新课程，例如更新课程名称？ Do you want to list an overview of all courses?您想列出所有课程的概览吗？ This would be an argument for extracting into an own collection.这将是提取到自己的集合中的一个论据。

So there is no general guideline for such migration as only from the schema definition, the use cases cannot be derived.因此，对于此类迁移没有通用指南，因为仅从模式定义中无法导出用例。

If you don't care about data, the best approach is to redesign it from scratch.如果您不关心数据，最好的方法是从头开始重新设计。

NoSQLs differ from RDBMS in many ways so direct mapping will hardly be efficient and in many cases not possible at all. NoSQL 在许多方面与 RDBMS 不同，因此直接映射几乎不会高效，并且在许多情况下根本不可能。

First thing you need to answer to yourself (and probably to mention in the question) is why you need to change database in the first place.您需要回答自己的第一件事（并且可能在问题中提到）是为什么首先需要更改数据库。 There are different kind of problems that Mongo can solve better than SQL and they require different data models. Mongo 可以比 SQL 更好地解决不同类型的问题，它们需要不同的数据模型。 None of them come for free so you will need to understand the tradeoffs.它们都不是免费的，因此您需要了解权衡取舍。

You can start from the very simple rule: in SQL you model your data after your business objects and describe relations between them, in Mongo you model data after queries that you need to respond to.您可以从非常简单的规则开始：在 SQL 中，您在 model 中您的业务对象之后的数据并描述它们之间的关系，在 Mongo 中，您需要在查询后响应您的 model 数据。 As soon as you grasp the idea it will let you ask answerable questions.一旦你掌握了这个想法，它就会让你提出可以回答的问题。

It may worth reading https://www.mongodb.com/blog/post/building-with-patterns-a-summary as a starting point.作为起点，可能值得阅读https://www.mongodb.com/blog/post/building-with-patterns-a-summary 。

An old yet still quite useful https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1 Just keep in mind it was written long time ago when mongo did not have many of v4+ features.一个旧但仍然非常有用的https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1请记住它是很久以前写的mongo 没有很多 v4+ 功能。 Nevertheless it describes philosophy of mongo data modelling with simple examples.It didn't change much since then.尽管如此，它还是通过简单的示例描述了 mongo 数据建模的理念。从那时起，它并没有太大变化。