4

关于表结构的问题。

这里有一个小场景来介绍这个问题：假设你想在一个表中存储一个类（let A）的对象。

您有两种可能的表结构来执行此操作：

Structure A: "one field per row":
id (int),
name (text),
credit (int),
birthday (date).

Structure B: "all data in one row":
id (int),
data (bigtext).

考虑以下：

  • 您将永远不会执行请求过滤/排序字段名称/信用/生日
  • 在编辑字段之前，您要加载对象
  • 字段名称/信用/生日没有选项/修饰符（键/唯一/...）

这两个表结构有什么区别？

.

具体来说，我正在做一个 PHP/SQLITE 应用程序 - 在某一时刻 - 需要将对象存储在数据库中。我希望能够轻松添加 db-stored-class 而不必每次都编辑我的数据库方案。使用“结构 B”可以让我这样做。它可能看起来很脏，是的，你可能已经被教导你需要有很好的类型行..但为什么不呢？

“结构A”的主要优势不只是选择过滤器和更新的有效性吗？

4

4 回答 4

2

永远不要用关系数据库对一个字段中的所有数据进行示例二。这是 WAYY 更多的努力和更少的灵活性。

如果在一年后你想创建另一个访问数据库的项目，你将不得不重复大量的验证、提取等工作，而如果一切都在一个单独的列中，那就容易多了。

你说“你永远不会执行请求过滤/排序字段名称/信用/生日”我非常怀疑它会以这种方式工作。您在软件开发中快速学到的一件事是，诸如“哦，那永远不会发生”之类的陈述总是会回来咬你的屁股

如果你真的想采用 b) 的方法，至少看看 nosql。我对此了解不多，但如果这是您想要采取的路线，它将比 RDBM 更适合您的项目

于 2012-09-08T16:43:24.370 回答
1

您正在谈论在业务层/Web 应用程序中处理所有数据完整性，这在当今是完全可以接受的。

与其完全使用表结构，不如只存储一个 JSON 对象？这样您就不必担心架构更改，您只需序列化/反序列化对象以供前端使用。

也许考虑使用键/值存储（一种 NOSQL 解决方案）来处理类似的事情，尽管任何数据库都足够了。

要回答您的问题 - 不同之处在于能够查询字段、验证数据、维护数据完整性等，而在结构 B 中，您在应用程序的数据库之外处理所有这些。

关于您对无法查询对象的感知限制，MapReduce 将允许您对 JSON 数据运行聚合查询。

如果您需要灵活性并且不需要结构化数据库提供的其他好处，请选择选项 B，如果您想验证数据库中的数据并更轻松地在其上运行查询，请选择选项 A。

结构 A 的优点是接近数据的数据完整性规则，以及以多种不同方式轻松查询数据的能力。

结构 B 的优点是可扩展性和可伸缩性 - 您可以在应用程序中轻松更改数据结构，并且如果您需要扩展，您可以轻松地对数据进行水平分区。

于 2012-09-08T16:24:50.067 回答
0

不。例如，类型安全呢？在结构 B 中，是什么阻止我将我的生日宣布为“永无的 12 日”、“红色”或“3.1415”？

于 2012-09-08T16:16:42.740 回答
0

为什么要使用关系数据库？使用单独字段的优势通常超过将所有数据分组到一个字段中的优势。您为什么不希望您的数据已经正确拆分和输入？

无论如何，请参考禁止非原子数据的第一范式（以及第二和第三范式）。如果您的代码是某些专业工作的一部分，您可能应该遵循它们。

于 2012-09-08T16:21:42.253 回答