我有一个asp.net应用程序,它使用很多主数据,如货币,国家,城市和许多其他领域特定的主数据。当前数据库模型为每种类型的主数据都有一个主表。例如,国家/地区具有单独的主数据表,其中包含ID和值列。与所有其他主数据类似。这是管理主数据的正确方法吗?我愿意彻底改变它。我想对此有所了解。还有没有任何文章或书籍可以帮助我在数据库建模中为这些场景做好准备?
答案 0 :(得分:3)
在关系设计和数据建模中,没有“主”数据这样的东西,也没有“主”表这样的东西。只有数据和表格。
因此,如果您需要存储某些国家/地区的数据,即使只是他们的名字,也可以创建一个国家/地区表。但是,请勿使用ID号。使用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
然后你会创造更糟糕的问题,因为你有更多的桌子而不是你所熟悉的。这种反模式的通用名称是“The One True Lookup Table”。
首先,外键在这里没用,因为没有办法向用户显示可供选择的有效国家,城市或货币的列表。如果用户只是从该表中选择值,则英格兰伦敦的用户可能会输入“Eury,Aughagower”。
其次,这是一个事实上不正确的模型。 “伦敦”不是指定城市的名称;不过,“伦敦,英国,英国”,“伦敦,安大略省,加利福尼亚”和“伦敦,肯塔基州,美国”都是如此。如果您的数据库允许名为“旧金山,阿拉巴马州,美国”的“城市”,那么您就无法正常工作。
第三,该模型不能完全扩展。仅货币比其名称具有更多有用的属性。旧的英镑有一个符号,£和ISO代码,GBP。我记不起过去30年来我使用货币名称而不是其符号或ISO代码生成的任何报告。
最后,正确建模数据不会“污染”数据库,也没有“迷你表”这样的东西。正确建模数据可简化您的工作,并简化应用程序代码。当你做一个合适的关系模型时,每个表只存储一种事实。如果您遇到问题,您将确切地知道要查找的位置 - SQL错误消息几乎总是命名导致问题的表。使用国家/地区表解决问题比使用可能存储50种或更多不同类型事实的“主”表更容易。
如果表的数量太多,请考虑将其中一些放在不同的模式中。随着您获得经验,处理大量有名的表将成为第二天性,您将学会忽略与您的直接任务无关的表。
答案 1 :(得分:3)
为查找数据的每个种类设置一个单独的表是合理的。这样可以正确实施参照完整性。
E.g。 COUNTRY_ID
字段(在某些“非查找”表中)有一个FOREIGN KEY引用COUNTRY
表,CURRENCY_ID
引用CURRENCY
表等...每个字段引用适当的表对于那个特定的领域。