我有这个使用自然主键的应用程序。数据库使用WE8ISO8859P15字符集。所以在我的表格中，City有主键，如'MEDELLÍN'和'MÜNCHEN'。我有预感，我们将会遇到很多麻烦。
我看到的问题
我们应该允许PK中的变音符号吗？请随时发表您的意见。
答案 0 :(得分：5)
试图忽略变音符号只是推迟不可避免的事情。是的，你可以在东欧保存一些问题。但你仍然无法处理希腊城市名称。你需要Unicode，然后再拼错Munchen / Muenchen就没有意义了;这是慕尼黑。
也就是说，一个城市有一个单一名称的概念已经在布鲁塞尔又名布鲁塞尔，而那是西欧。因此，无论你如何拼写它们，它们都基本上不适用于主键。
答案 1 :(得分：4)
为什么不呢？你的数据库模型已经无法修复，为什么不引入另一个问题来源呢？ ;）
更严重的是，数据库在支持Unicode方面变得越来越好，因此存储自然文本没有问题（尽管它有些奇怪）。您的问题是“主键”。有几种方法可以对相同的文本进行编码（例如，您可以使用带有明文字符的重音字符或变音符号）。这意味着您可以为同一文本获得两个不同的密钥。
将业务密钥用作PK并且没有好的原因有很多错误的原因。不要这样做。咬紧牙关并修复它。立即修复它。它会花费你更少（即使它花费很多）而不是修复它。
答案 2 :(得分：3)
和你一样，我觉得它真的会找到问题来允许它们。
除了你提到的问题，它可能是：
我不知道是否可以选择引入代理主键，但这可能是正确的时机;-) ...
如果没有，您可以复制列：
答案 3 :(得分：3)
是的，你会遇到这些角色的问题。离开ASCII总是会导致问题。但是，当你不仅在英国和美国做生意时，你就没有选择。
我没有看到主键的特殊字符集相关问题。如果您导出，导入，界面或迁移，您将不得不考虑这些角色，无论它们是否属于您的PK。
但他们确实强调自然键作为主键的问题。似乎有人会写一个例如Muenchen稍后将其改为慕尼黑，这当然会引起众所周知的PK更新问题。
答案 4 :(得分：3)
您的属性是否是某个键的一部分与该问题无关。
无论如何，您都会遇到与此属性之间的任何数据流量进行字符集转换的问题，无论是否为关键字。
是的，为了“正确”编码，并且尽可能保证您的数据永远不会因字符集转换问题而损坏，您需要Unicode字符集及其编码之一。
顺便说一句，我确实对桌子本身有一些严重的怀疑。你怎么处理德国的海德堡和南非的海德堡？牛津，英国和美国的牛津，哪里甚至几乎没有一个州？
哪种信息取决于该密钥？如果根本没有，那么你的表更像是一个“变量类型”而不是“真正的表”。在这种情况下，您可能也会忘记该表，并使您的cityname属性只是简单的String。
如果您真的需要在从数据库导出数据时为城市名称生成一些“规范拼写”，那么我建议尝试设置一个“拼音搜索表”，其中“常用拼写”链接到你需要制作的“规范拼写”。但是，期望在填充此类表格方面做出认真的努力。
在这种情况下，除了已经提到的慕尼黑/慕尼黑和西方/希腊字母表问题之外，不要忘记Liège/ Luik /Lüttich（慕尼黑/慕尼黑）的问题。
答案 5 :(得分：1)
事情会改变他们的名字，或者为他们改名。城市，大学，公园，人......都不适合作为主要钥匙。也许唯一的钥匙？或者是Unique Key的一部分？