关于表结构的问题。
下面是一个小场景来介绍这个问题：想象一下，您想要将类（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).
考虑以下内容：
- 您永远不会执行过滤/排序字段名称/信用/生日的请求
- 在编辑字段之前，您需要加载对象
- 字段名称/信用/生日没有选项/修饰符（keys/unique/…）
这两种表格结构有什么区别
具体来说，我正在做一个PHP/SQLITE应用程序，它一度需要将对象存储在数据库中。我希望能够很容易地添加数据库存储类，而不必每次都编辑我的数据库方案。使用"结构B"可以做到这一点。它可能看起来很脏，是的，你可能已经被教导你需要有漂亮的打字行。。但为什么不呢？
"结构A"的主要优点难道不只是选择过滤器和更新的有效性吗？
永远不要用关系数据库的一个字段中的所有数据来做第二个例子。WAYY付出了更多的努力，灵活性也大大降低。
如果一年后你想创建另一个访问数据库的项目，你将不得不重复大量的验证、提取等工作，而如果所有内容都在一个单独的列中，那会容易得多。
你说"你永远不会执行过滤/排序字段名称/信用/生日的请求"我非常怀疑它会以这种方式运作。在软件开发中，你很快就会学到一件事，那就是像"哦，那永远不会发生"这样的语句总是会反噬你的屁股
如果你真的想采用b）的方法，至少可以看看nosql。我对它了解不多，但如果你想采用
您谈论的是在业务层/web应用程序中处理所有数据的完整性，这在目前是完全可以接受的。
与其使用表结构，为什么不直接存储一个JSON对象呢？这样，您就不必担心架构更改，只需序列化/反序列化对象即可与前端一起使用。
也许可以考虑使用键/值存储（NOSQL解决方案）来实现类似的功能，尽管任何数据库都足够了。
为了回答您的问题，不同之处在于能够查询字段、验证数据、维护数据完整性等，而在结构B中，您在应用程序中的数据库之外处理所有这些。
关于无法对对象进行查询的限制，MapReduce将允许您对JSON数据运行聚合查询。
如果您需要灵活性并且不需要结构化数据库提供的其他好处，请选择选项B；如果您想在数据库中验证数据并更容易地在数据库上运行查询，请选择选择选项a。
结构A的优点是数据完整性规则接近数据，并且能够以多种不同的方式轻松查询数据。
结构B的优点是可扩展性和可扩展性——您可以在应用程序中轻松地更改数据结构，如果需要扩展，还可以轻松地对数据进行水平分区。
否。例如，类型安全性如何？在结构B中，是什么阻止我宣布我的生日是"从未有过的12号"、"红色"或"3.1415"？
为什么要使用关系数据库？使用单独字段的优势通常超过将所有数据分组在一个字段中的优势。你为什么不希望你的数据已经被拆分并正确键入？
在任何情况下，请参考第一范式（以及第二范式和第三范式），它禁止非原子数据。如果你的代码是一些专业工作的一部分，你可能应该遵循它们。