主数据的表设计

Question

我有一个asp.net应用程序，它使用了大量的主数据，如货币、国家、城市和许多其他领域特定的主数据。当前数据库模型中，每种类型的主数据都有一个主表。例如，国家/地区有一个单独的主数据表，其中包含一个ID和一个值列。类似于所有其他主数据。这是管理主数据的正确方式吗？我对彻底改变它持开放态度。我想了解一下这方面的意见。另外，有没有什么文章或书籍可以让我在db建模中准备好这样的场景？

Answer 1

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

因此，如果您需要存储有关国家的某种数据，即使只是它们的名称，那么可以创建一个国家表。不过，不要使用身份证号码。使用ISO country code。它是人类可读的(在大多数情况下)，不需要连接。并确保在名称上有唯一的约束，而不仅仅是代码。如果你可以将两个国家命名为“爱尔兰”，那你就错了。

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

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

如果你在谈论一个像这样的“主”表。。。

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

那么你就会制造出更糟糕的问题，因为你的桌子比你习惯的多了几张。这个反模式的通用名称是“One True Lookup Table”。

首先，外键在这里没有用处，因为没有办法向用户显示可供选择的有效国家、城市或货币的列表。如果用户简单地从该表中选择值，则英国伦敦的用户可能会改为输入"Eury，Aughagower“。

其次，这是一个事实上不正确的模型。“伦敦”不是一个特定的城市名称；“伦敦，英格兰，英国”，“伦敦，安大略省，加利福尼亚州”和“伦敦，肯塔基，美国”是一个特定的城市名称。如果你的数据库允许“城市”命名为"San Francisco，Alabama，USA"，那么你就没有做好你的工作。

第三，该模型不是完全可扩展的。货币本身具有比其名称更有用的属性。旧时的英镑有一个符号GBP和一个ISO代码GBP。我想不起在过去的30年里，我写过的任何报告都没有使用货币的名称，而不是使用它的符号或ISO代码。

最后，正确的数据建模不会“污染”数据库，并且没有“迷你表”这回事。正确地对数据进行建模可以简化您的工作，还可以简化应用程序代码。当您使用适当的关系模型时，每个表将存储且仅存储一种类型的事实。如果您有问题，您将确切地知道去哪里查找--SQL错误消息几乎总是命名导致问题的表。使用国家/地区表来解决问题要比使用“主”表容易得多，因为“主”表中可能存储了50种或更多不同类型的事实。

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

Answer 2

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

例如，COUNTRY_ID字段(在一些“非查找”表中)有一个引用COUNTRY表、CURRENCY_ID引用CURRENCY表等的外键。每个字段引用适用于该特定字段的表。