在标题可能发生变化的情况下，存储数据的最佳规范化方法是什么[关闭]答案

【问题标题】：What is the best normalized way of storing data where titles are subject to change [closed]在标题可能发生变化的情况下，存储数据的最佳规范化方法是什么[关闭]
【发布时间】：2014-12-11 01:01:57
【问题描述】：

我有一个可以保存“游戏统计”的表格。所持有的统计数据的名称将根据统计数据所针对的运动而改变。

最好的做法是制作两张表：一张用于包含“Stat1、Stat2”等列的统计信息，另一张用于保存以 sportID 作为键的标题。或者最好的做法是为每项运动的度假村设置几张桌子。还是其他方式？

谢谢，

【问题讨论】：

根据我的经验，不同运动的统计数据很难用单一的数据库结构来表示。所以我可能会为每项运动使用单独的数据库。

标签： mysql sql sql-server normalization

【解决方案1】：

我同意安迪。像Stat1 这样的通用标题列 - 在列名称中未指定用途、以多态方式使用或必须使列类型更通用 - 通常表明 SQL/RA 设计不佳。

考虑是否遇到过这种情况：create table people (field1 varchar(20), field2 varchar(20))。是的 - 不会在我的数据库中飞行。给出与目的相关的列（和表）名称。

相反，收集的每种不同类型信息都应该有自己的实体（阅读：表格）或相关实体组。在这种情况下，我会想象每项运动代表不同类型的收集统计/信息。（甚至输赢信息也会因运动而异。）

尝试根据附加表“标记”列是Entity-Attribute-Value (EAV) 模型的中途尝试。虽然 EAV 可以很有用，但它在 SQL 中具有很多的缺点，除非经过对特定用例的仔细考虑，否则不应使用它。（我确实不相信 EAV 适合这种情况。）

【讨论】：

问题是，如果我每张桌子做一张，那么我需要制作大约 100 张桌子。我认为 EAV 可能是这种方式
@LiamHT EAV 不是这种方式。我保证（尽我所能在stackoverflow上发表评论......）。会有很多哭泣和咬牙切齿（尤其是在尝试构建适当/有用的查询时！），但它是一条路径..我会考虑使用模板/生成器来创建表格以及相关的 DAL 来访问它们。也就是说，动态/映射层可以（并且通常应该）移动到模型本身的外部。
我会考虑的，谢谢你的帮助
我想我找到了工作的替代方案，这很有趣。我首先创建了一个统计表，它有一个简单的 id 和名称，以及一个描述，以防我决定在这里列出规则。这个想法是为每项运动的统计数据设置一行，而不是在多项运动之间交叉引用。出于描述的目的，我使用现有的夹具表链接到一个新的“夹具玩家表” - 给我一个谁在玩哪个游戏的列表。然后我可以从那里创建一个 ResultStats 表，它可以引用 playerfixture ID。