是数据关系还是数据库设计？

Question

我是数据库领域的新手，并且陷入了这种困惑。我正在努力将脱机应用程序的数据库层从sqlite转换为IndexedDB。 目前，SQLite中的数据库具有高度的关系性。在此数据库上发生的查询太多是连接查询。 当我开始将这个数据库转换为适合IndexedDB（NoSQL）的数据库时，我想知道：

关系数据库布局是否可以重新编写并转换为属于NoSQL世界的设计（不需要任何连接）？换句话说，可以将同一数据同时建模到关系数据库和NoSQL数据库中。或关系/非关系是数据的属性，数据应该规定是否需要非关系数据库或关系数据库？

Answer 1

导致您更改后端数据库的初始要求是什么？如果性能，尝试使用更“强大”的SQL数据库引擎（MySQL，PostgresQL），你可能会获得x30！对于现有的复杂数据模型，如果暗示非精确匹配，NoSQL不是一个简单的转换，甚至不是一个好的选择（除非使用评分机制，反向映射，所以“技巧”会使客户端代码复杂化）

NoSQL选择通常意味着您必须定义noSQL模型以适应您需要执行的操作。因此，您知道必须对数据执行哪些请求，并根据您希望对其执行的请求构建NoSQL模型。如果对所需请求的要求发生变化，则可能必须重新创建NoSQL模型以适应新请求。

SQL选择更灵活，允许您对现有数据进行任何操作，对数据结构（如果有）的影响很小，因为关系足以获得所请求的数据。但就原始性能而言，它不会与NoSQL竞争。

所以灵活性与安全性之间的永恒选择性能！

使用NoSQL =＆gt;性能超过灵活性=＆gt;处理需求变更的更多工作，复杂操作的复杂代码，专用客户端界面和编码。

使用SQL =＆gt;灵活性超过性能=＆gt;处理需求变更的工作量减少，“规范化”（带引号）SQL语言隐藏了大部分复杂性，“通用”客户端界面＆amp;编码。通过改变引擎可以减轻性能问题。

Answer 2

我不知道你为什么要在SQL和NoSQL中建模数据库，但是，可以将SQL模式“转换”为NoSQL。使用NoSQL，您的应用程序通过它的模型类而不是SQL来定义您的模式，您可以在数据库中定义模式，然后围绕它构建模型。为了解释关系，你只需将你的一个字段设置为多值，如hashmap等......取决于你正在使用的NoSQL解决方案。

Answer 3

Relational是一种建模数据的方法。在关系模型下，原始数据经历称为规范化的分析过程。在规范化期间，数据被分成实体，关系和属性。请参阅here。

标准化是一个可逆的过程。虽然总是可以做到这一点，但并不总是明智的。例如，由于冗余数据，完全非规范化可能导致数据库大小的爆炸。对数据库中的查询的灵活性和处理时间的增加通常也会降低。插入变得乏味，因为所有实体都在一个表中表示。因此，如果实体被扩大，则必须扩大所有实体。