关于表格结构的问题。
这是一个介绍问题的小方案： 想象一下，你想要将一个类的对象（让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，而不必每次都编辑我的db方案。使用“结构B”将允许我这样做。 它可能看起来很脏，你可能已经被教导你需要有一个很好的打字行......但为什么不呢？
“结构A”的主要优势不仅仅是选择过滤器和更新的有效性吗？
答案 0 :(得分：2)
永远不要在一个字段中使用关系数据库执行示例二的所有数据。这是更多的努力，并且灵活性较低。
如果在一年后你想要创建另一个访问数据库的项目，你将不得不复制许多验证，提取等工作，而如果所有内容都在一个单独的列中，那将更容易。
你说“你永远不会执行请求过滤/排序字段名称/信用/生日” 我非常怀疑它会以这种方式运作。你在软件开发中快速学到的一件事就是“哦，永远不可能发生的事情”这样的陈述总会让你感到厌烦。
如果你真的想采用b）的方法，至少要看看nosql。我不太了解它，但如果这是你想要的路线，它将比RDBM更适合你的项目
答案 1 :(得分：1)
您正在谈论在业务层/网络应用中处理所有数据完整性，这些日子完全可以接受。
为什么不只是存储JSON对象，而不是完全使用表结构？这样您就不必担心架构更改，只需序列化/反序列化对象即可用于前端。
也许考虑使用键/值存储（NOSQL解决方案）来做这样的事情，尽管任何数据库都可以满足。
回答你的问题 - 区别在于能够查询字段，验证数据，维护数据完整性等，而在结构B中，你在应用程序中处理数据库之外的所有这些。
关于无法查询对象的感知限制，MapReduce将允许您对JSON数据运行聚合查询。
如果您需要灵活性并且不需要结构化数据库提供的其他好处，请转到选项B，如果要在数据库中验证数据并更轻松地运行查询，请转到选项A.
结构A的优点是接近数据的数据完整性规则，以及以多种不同方式轻松查询数据的能力。
结构B的优点是可扩展性和可扩展性 - 您可以在应用程序中轻松更改数据结构，如果需要扩展，则可以轻松地对数据进行水平分区。
答案 2 :(得分：0)
没有。那么，例如，类型安全呢？在结构B中，是什么阻止我宣布我的生日是“永远的第12个”，或“红色”，或“3.1415”？
答案 3 :(得分：0)
为什么要使用关系数据库？使用单独的字段通常的优点超过了仅在一个字段中对所有数据进行分组的优点。为什么您不希望您的数据已经正确分割和输入？
在任何情况下，请参阅禁止非原子数据的First Normal Form（以及第二和第三）。如果您的代码是某些专业工作的一部分，您应该遵循它们。