-1

我正在尝试以各种方式评估构建我的数据模型的利弊，我想知道我是否会通过将相当复杂的嵌套数据类型填充到 SQL 表的各个列中来打击自己.

例如，假设我想序列化一个结构数组（或者更糟糕的是，哈希数组）并将其保存在单个列中。它很可能是一个有点嵌套的 JSON 字典。就像是：

user_id | user_related_data_blob
---------------------------
1       | { .... }

我可以立即看到的明显缺点是数据耦合，以防某些数据与用户的关系不是很紧密。还有每个检索到的行的大小，这可能会使从 Web 获取相当慢，尤其是在大多数数据甚至不是客户端立即需要的情况下。通过这些列执行 SQL 也变得相当复杂（并且可能不可索引），除非有特殊的技术来支持它。

几乎唯一的好处是，如果您不想创建复杂的模式并花费大量时间确保所有约束都是合理的并且您拥有的约束更少移动部件。对于像快速原型这样的东西，它甚至可能是有意义的。

我在这里错过了什么吗？SQL 世界中是否有一条经验法则规定您永远不应将数据嵌套在单个列中？有什么好的指导方针吗？

4

3 回答 3

2

SQL 世界中是否有一条经验法则规定您永远不应将数据嵌套在单个列中？

开始的第一个范式。也许您正在寻求 NoSQL 解决方案？

于 2013-01-20T08:42:22.133 回答
0

在 SQL 数据库中存储 blob 数据是个坏主意，因为 SQL 不理解它，也没有提供有用的工具来处理它。

  1. 无法搜索或过滤 BLOB 数据
  2. 没有办法只检索 BLOB 的一部分，要么全有要么全无
  3. 大多数 SQL 数据库不是为处理 BLOB 而在内部构建的

您可以找到一个肮脏的解决方法，使用 SQL 中的字符串操作来获得对 blob 内容的一些有限访问，但是这些将非常非常缓慢且难以实现和维护。

但是当嵌套文档是表达数据的最佳方式时，您应该考虑使用面向文档的数据库，例如 MongoDB 或 CouchDB，它们提供了搜索、过滤和修改文档的各个字段的工具。

于 2013-01-20T13:42:42.933 回答
0

一个主要问题是您可能需要将数据检索到另一个环境中才能有效地更新它，而不太可能以最有效的方式访问它。例如，Postgres 有一个 json 数据类型和一些用于检索和存储数据的功能，包括类型验证，但是您仍然需要从数据库中检索对象，在代码中将其序列化，然后以您想要的方式访问它。

如果您必须以特定格式存储数据，那么由于数据存储种类繁多，我会寻找围绕该格式设计的选项。例如，Mongo 和 Couchbase 是存储 JSON 编码数据的出色引擎，允许您将 JSON 对象作为其自然类型进行访问。

回到 Postgres，它确实提供了 row_to_json() 函数，该函数将返回格式化为 JSON 的表行。如果您可以轻松地将 JSON 数据映射到平面表结构，这可能会提供一些可能性。当然，它对非结构化或半结构化数据没有帮助。

于 2013-01-20T11:22:45.487 回答