bto*_*own 4 schema database-design metadata eav
我正在尝试构建一个系统，该系统将收集对许多（30 万+）个对象中的每一个的各种数量（10+）的估计，并根据这些估计的历史记录做出决策。例如，我们有许多人工和自动化流程可能试图确定一个对象的，例如 PowerLevel，并且当它们报告的结果可能（或可能不会）相互替代时，我们想跟踪历史这些报告以及来自流程的元数据（日期、调整参数、代码版本等）。具体来说，我们可能想要执行诸如“按实体 id 分组，对于每个不同的属性，查找最新估计”或“查找其属性具有由代码库 573ae4 运行的任何更新的所有实体”之类的查询。
作为从未在生产中实际使用实体属性值模式的人，这似乎是 EAV 之类的完美用例，为源提供额外的元数据列。具体来说，我会设想一个这样的表格：
entity_id | attribute_id | string_value | numeric_value | datetime_value | discovery_time | discovery_source | discovery_tuning_parameters | discovery_code_hash
但是我听到了很多对这些类型架构的批评，例如这个答案。我很难找到在非遗留系统上使用 EAV 的人，这让我非常犹豫，我可能会重新发明一个非常过时的轮子......
另一方面，我能想到的唯一其他选择是完整的 NoSQL (bleh) 或一些邪恶的混合体，例如：
id | power | power_current_discovery_date | power_current_discovery_source | power_history (an array of hstores?) | foobar | foobar_current_discovery_date | ...
因为我们需要每个属性的元数据。
有什么想法吗？这是 EAV 适合的少数几次之一吗？谢谢你的帮助！
EAV 不是邪恶的；与任何其他工具一样，它可能实施不当并被滥用。您可以找到垃圾谈论游标、动态 SQL、触发器，甚至 SQL Server 本身的文章。这不会使他们成为坏事。
EAV 可能是一个合适的解决方案。在您的特定情况下，它是否是正确的答案可能比任何事情都更基于意见；我的回答更多是为了建议您不要因为有人说这很糟糕而对解决方案闭门造车。总是有相反的观点需要考虑：