对于我的国家表，我使用了 国家代码作为主键“AU， 美国，英国，法国“等等
对于我的货币表，我使用货币代码作为主键“AUD，GBP，USD”等
我认为我所做的是好的，但另一位开发人员希望我将所有主键更改为int，因为国家代码，货币代码可能会在未来的某个时间发生变化。我们只是不知道，在这种情况下他是对的，他的道路是最安全的道路。
我应该将主键更改为int是安全的而不是抱歉吗？我不能保留它吗？
答案 0 :(得分：14)
我会使用带有char列的ISO代码。
如果某个国家/地区分裂，那么您将获得新的ISO代码（例如SC，WL，EN），但英国仍然有效以获取历史数据。
货币也一样。 2000年的交易将使用当时的货币：法国法郎，德国马克，比利时香蕉，但不是欧元。
答案 1 :(得分：3)
我会说“一个国家的诞生”或者一种货币的消失 - 一种相当罕见的 - 每年都不可能发生几次。
所以在这方面，我认为使用ISO定义的国家和货币代码作为主键应该没问题。
是的，如果欧元区出现问题，或者另一个国家被分成两部分，您可能需要进行一些手动内务管理 - 但您也必须使用INT进行此操作。在这样的情况下，我认为人工代理键（如INT）实际上只会增加开销，并没有真正帮助使事情变得更容易/更明确。
由于这些代码非常短，通常长度相同，但我建议使用CHAR(3)或CHAR(5) - 使用VARCHAR来表示这么短的字符串没有意义，而且，作为可变长度字段的VARCHAR在固定长度字段（例如INT或CHAR
答案 2 :(得分：3)
从逻辑的角度来看，添加代理意味着额外的列，额外的键约束和更复杂的逻辑来查询和操作数据。这是一件需要考虑的事情。
从物理角度来看，在SQL Server中，INTEGER键占用的空间是CHAR（2）或CHAR（3）的两倍多。这意味着您的引用表和索引会变大。它还使这些外键值的任何更新都更加昂贵。我不知道您的数据，但很可能这些外键列中的引用数据可能比父表中的国家/地区代码和货币代码值更频繁地更新。相比之下，货币和国家的ISO代码几乎从未改变，因此可能很少担心。通过更改为INTEGER键，您可以增加更新这些外键值的成本。
如果您正在考虑将此类更改作为性能优化，那么我建议您仔细评估INTEGER密钥是否会使这些值的更新成本更高或成本更低。我建议你忽略那些说“永远做X”的人。 Dogma在数据库设计方面没有帮助。评估实际影响，并做出相应的决定。
答案 3 :(得分：1)
我认为，在有关国家和货币代码的ISO标准之前，您的系统将会过时十次。
所以我认为使用01010101 01010011或21843代替“US”并没有任何好处。
答案 4 :(得分：0)
只要引用这些主键的任何外键都用ON UPDATE CASCADE声明，如果这些代码发生变化，谁关心？
查询任何引用表还有一个额外的好处 - 如果您只需要国家/货币代码，那么就不需要加入这些表 - 您已经获得了这些表中的代码。
如果您决定转移到INT代理，请记住仍然在这些列上放置一个唯一的约束 - 它们是这些表的真正关键。
答案 5 :(得分：0)
我会使用INT ID作为键而不是ISO代码，并解释原因：
我工作的组织使用“自有货币”（LBP） - 例如，当用户执行某些交易时，他会收到一定数量的LBP作为奖金。此外，他可以将这些LBP兑换成美元，欧元等，反之亦然，用LBP等支付服务费。另外，我没有在ISO标准中找到BTC（比特币）货币。
是的，这些不是官方货币，但从系统和用户的角度来看，它更灵活地将它们作为货币而不是用户可以买卖的额外产品。
我工作的组织不使用INTS作为主键，他们使用ISO代码作为ID（加上那些额外的货币）。
据官方统计，LBP是黎巴嫩镑的ISO标准 - 因此他们无法顺利将黎巴嫩镑添加到系统中。
如果您按代码识别您的货币，并且将来某些新货币将被注册为ISO标准（例如，LBE或BTC） - 那么这些货币将与“您的”货币冲突。
有人在这里提到，为货币设置额外的int键是一个额外的索引。 但是，请问，300条记录（大致的货币数量）是一个问题吗？此外，如果您使用INT作为货币的主键，它还有一个额外的好处：想象一个包含1M交易的表，其中包含金额和货币，哪些更有效：INTS或CHARS？
所以我会选择INTs。
答案 6 :(得分：-2)
是的，在为时已晚之前更改为整数键是个好主意。
E.g。如果英国加入欧元区怎么办？
答案 7 :(得分：-2)
使用某些东西作为更改的主键是一种不好的做法。假设值已更改，然后您必须更新所有子记录。这样做可能会将数据库锁定数小时甚至数天。这就是为什么具有自然键上的唯一索引的整数FK对于易失性信息是更好的做法。