我正在开发一个项目，其中对象（例如产品）可能具有数百个属性。对象也可能具有不同的属性。因此，除了其他更明显的原因之外，设计具有数百列的单个表是没有意义的。它只是不可扩展。在我看来，键/值存储机制似乎是正确的方法（特别是Entity-Attribute-Value Model）。
此数据的另一个挑战是它需要可以覆盖。要描述此要求，请设想一个具有“推荐”产品属性的公司范围的零售产品数据库。但是在不同的地区，他们想要用自己的自定义值覆盖几个不同的属性，然后每个地区的一些特许经营权希望添加一个特定于其商店的额外覆盖。在遗留系统中，有多个表（每个表都有过多的列），我们使用COALESCE（在视图中）和代码的组合，根据我们的信息找到最具体的值知道（产品，地区，地点等）。
我的想法：
// An object could be a product, a car, a
// document, etc.
---------------------------------
| Table: object
---------------------------------
| - object_id
| - object_name
---------------------------------
// An attribute could be color, length, etc.
---------------------------------
| Table: attribute
---------------------------------
| - attribute_id
| - attribute_name
---------------------------------
// An owner could be a company, a region,
// a store, etc
---------------------------------
| Table: owner
---------------------------------
| - owner_id
| - parent_owner_id
| - owner_name
---------------------------------
// Object data would be a key/value specific
// to a specific object (entity), a specific
// attribute, and specific owner (override level)
---------------------------------
| Table: objectdata
---------------------------------
| - objectdata_id
| - object_id
| - attribute_id
| - owner_id
| - value
---------------------------------
在考虑这一点时，它满足要求＃1以获得可以轻松扩展的动态属性。但是对于＃2，虽然它提供了找出覆盖所需的数据，但它似乎是一个复杂的查询并且可能存在性能问题。例如，如果我从所有者 3级深度级别查看特定的对象，我需要获取在顶级定义的所有属性所有者他们没有父母，然后从每个级别获取属性，将它们合并，直到达到特定级别。
作为一个额外的奖励问题，每个属性可能是多种不同的数据类型（字符串，整数，浮点数，时间戳等）。我是否将它们全部存储为字符串并在应用程序级别处理所有验证？嗯。
TL; DR; 所以我的问题（和问题）是什么是有效的数据建模模式，我可以在其中动态添加和删除对象的属性以及具有某种父/用于根据一组约束确定大多数特定属性值的子关系？
注意：上面的零售示例是虚构的，但比实际情况更好地描述了问题。