关于表结构的问题.
这是一个介绍问题的小方案：
想象一下,您想要将类的对象(让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”的主要优势不仅仅是选择过滤器和更新的有效性吗？
解决方法
您正在谈论在业务层/ Web应用程序中处理所有数据完整性,这些日子完全可以接受.
而不是完全使用表结构,为什么不只是存储一个JSON对象？这样您就不必担心架构更改,只需序列化/反序列化对象即可与前端一起使用.
也许考虑使用键/值存储(NOsql解决方案)来实现这样的事情,尽管任何数据库都可以满足要求.
回答你的问题 – 区别在于能够查询字段,验证数据,维护数据完整性等,而在结构B中,你在应用程序中处理数据库之外的所有这些.
关于您无法查询对象的感知限制,MapReduce将允许您对JSON数据运行聚合查询.
如果您需要灵活性并且不需要结构化数据库提供的其他好处,请转到选项B,如果要在数据库中验证数据并更轻松地运行查询,请转到选项A.
结构A的优点是接近数据的数据完整性规则,以及以多种不同方式轻松查询数据的能力.
结构B的优点是可扩展性和可伸缩性 – 您可以在应用程序中轻松更改数据结构,如果需要扩展,则可以轻松地水平分区数据.
