数据是关系型还是数据库设计？ [关闭]答案

【问题标题】：Is the data relational or the database design? [closed]数据是关系型还是数据库设计？ [关闭]
【发布时间】：2012-09-23 11:59:49
【问题描述】：

我是数据库领域的新手，并陷入了这种困惑。我正在将离线应用程序的数据库层从 sqlite 转换为 IndexedDB。目前 SQLite 中的数据库是高度相关的。此数据库上发生的太多查询是连接查询。当我着手将此数据库转换为适合 IndexedDB (NoSQL) 的数据库时，我想知道：

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

【问题讨论】：

这个问题不应该被关闭。数据是否本质上是相关的，或者关系建模是否只是查看数据的一种方式，这个问题已经有了答案。答案是数据本质上不是相关的。 ER 模型正是为了填补这一空白而发明的。 ER 建模不会将分析偏向关系或非关系解决方案。如果我必须从 SQL 解决方案开始，然后朝着 nosql 解决方案努力，我会首先将现有解决方案逆向工程回 ER 模型，然后在此基础上设计 nosql 数据库。
NoSql 解决方案可能使用与外键完全不同的东西来实现关系。对 ER 进行逆向工程的一部分是删除外键，并用“关系”替换它们。另一部分是决定这些关系是需求中固有的还是仅仅是先前设计的解决方案的一部分。
@WalterMitty 谢谢！我的理解是 NoSQL 数据库没有关系。在我的方法中，我试图对我拥有的关系设计进行非规范化。但我发现我无法完全摆脱这些关系。我仍然有实体的 id 作为其他实体（外键）中的引用，我担心 NoSQl 不会通过不提供关系完整性约束来提供帮助。所以，我目前正试图弄清楚如何摆脱或表达 NoSQL 中的关系。你能不能给我一些关于“删除外键，并用“关系”替换它们的指示......
非规范化的关系设计仍然是关系设计。您需要从对需求的理解中消除关系偏见。这就是 ER 建模的初衷。在原始样式 ERD 中，关系由框之间的线表示，但不是由框内的外键实现。您可以在行尾放置一些符号来表示“可选”或“很多”。
一旦您生成了一个表达需求的 ERD，但不是在旧 SQL 解决方案中满足这些需求的方式，下一步就是在您的 NoSQL 环境中实现这些关系，使用您的任何机制目标数据库为此目的提供。我不知道如何在您的目标数据库中执行此操作。

标签： database-design nosql relational-database

【解决方案1】：

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

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

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

所以灵活性和性能之间的永恒选择！

NoSQL => 性能优于灵活性 => 处理需求更改、复杂操作的复杂代码、专用客户端界面和编码需要更多工作。

使用 SQL => 灵活性优于性能 => 处理需求更改的工作量更少，“规范化”（带引号）SQL 语言隐藏了大部分复杂性，“通用”客户端界面和编码。性能问题可以通过更改来缓解引擎。

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

【讨论】：