Database design 主数据表设计

我有一个asp.net应用程序，它使用了大量的基础数据，如货币、国家、城市和许多其他特定于域的基础数据。对于每种类型的主数据，当前数据库模型都有一个主表。例如，国家有一个单独的主数据表，其中有一个ID和一个值列。与所有其他主数据类似。这是管理主数据的正确方法吗？我愿意完全改变它。我想征求一些意见。还有什么文章或书籍可以让我为db建模中的这种场景做好准备吗？

在关系设计和数据建模中，没有“主”数据，也没有“主”表。只有数据和表格

所以，如果你需要存储一些关于国家的数据，即使只是它们的名字，那么就创建一个国家表。不过，不要使用身份证号码。使用。它是人类可读的（大部分情况下），无需连接。并确保名称上有唯一的约束，而不仅仅是代码。如果你能把两个国家命名为“爱尔兰”，那你就错了

仔细考虑应该允许谁插入、更新和删除该表中的行。“每个人”几乎肯定是错误的答案

当其他表需要存储现有国家/地区的代码时，这些表会向国家/地区表声明一个外键

如果你说的是像这样的“主”桌子

ID    Name
--
1     England
2     London
3     Birmingham
4     Liverpool
5     British Pound (sterling)
6     Republic of Ireland
7     Aughagower
8     Ballyshannon
9     Euro

然后，你会制造更糟糕的问题，因为你的桌子太多了。此反模式的通用名称是“一个真正的查找表”

首先，外键在这里是无用的，因为无法向用户提供有效国家、城市或货币的列表供选择。如果用户只是从该表中选择值，则英国伦敦的用户可能会输入“Eury，Aughagower”

其次，这是一个事实上不正确的模型。“伦敦”不是一个指定的城市名称；“伦敦，英格兰，英国”，“伦敦，安大略省，加利福尼亚州”和“伦敦，肯塔基州，美国”是。如果您的数据库允许名为“美国阿拉巴马州旧金山”的“城市”，那么您的工作做得不好

第三，该模型的可扩展性不强。单是货币就比它们的名字更有用。旧的英镑有一个符号，英镑和一个ISO代码，英镑。我想不起在过去30年里我制作的任何报告中使用了货币的名称而不是其符号或ISO代码

最后，正确地建模数据不会“污染”数据库，也没有“迷你表”这样的东西。数据建模正确地简化了您的工作，并简化了应用程序代码。当您建立一个适当的关系模型时，每个表将只存储一种事实。如果您有问题，您将确切地知道在哪里查找——SQL错误消息几乎总是命名导致问题的表。与存储50种或更多不同类型事实的“主”表相比，使用国家表解决问题要容易得多

---

如果表的数量太多，可以考虑将其中一些表放在不同的模式中。随着经验的积累，处理大量命名良好的表将成为第二天性，您将学会忽略与当前任务无关的表。

对于每种查找数据都有一个单独的表是合理的。这允许适当地执行引用完整性

---

例如，

COUNTRY\u ID

字段（在某些“非查找”表中）有一个外键引用

COUNTRY

表、

CURRENCY\u ID

引用

CURRENCY

表等。。。每个字段都引用适用于该特定字段的表。

我不确定是否理解。你是说你有一个类似国家、货币、城市等的表格，它们基本上只是键值对，对吧？@MattGrande。是的，没错。他们通常在前端填写下拉列表。我想那没关系。继续这样做！我看到许多生产软件使用主数据表（一个大表，存储那些只有“ID”和“Name”属性的实体）。我发现这个设计有缺陷，但另一个选项使用几个迷你表来处理数据库方案。所以主数据是一种糟糕的设计实践吗？@CarlosGavidia：是的，“主”表是一种糟糕的设计实践。请参阅我的最新答案。