征求意见:主键中的重音符号/变音符号

试图忽略变音符号只是在拖延不可避免的事情。是的,你可以挽救东欧的一些问题。但你仍然不能处理希腊城市名称。你需要Unicode,这样就没有必要再拼错Munchen/Muenchen了;是陈先生。

也就是说,一个城市只有一个名字的概念已经在布鲁塞尔(Brussel又名Bruxelles)被打破了,那就是西欧。所以,不管你怎么拼写,它们基本上不适合主键。

为什么不呢?您的DB模型已经无法修复了,为什么不引入另一个问题源呢?;)

更严重的是,数据库在支持Unicode方面做得越来越好,因此存储自然文本(尽管有些奇怪)没有问题。您的问题是“主键”。有几种方法可以对同一文本进行编码(例如,可以使用重音字符或带普通字符的变音符号)。这意味着您可以为同一文本获取两个不同的键。

使用商业密钥作为PK有很多错误的理由,但没有好的理由。不要这样做。咬紧牙关,把它修好。现在修好它。它将比不修复它花费更少(即使花费很多)。

像你一样,我觉得 这真的是在寻找问题 允许他们。

除了您提到的问题外,还可能是:

• 想象一下切换到另一个数据库供应商。。。

我不知道是否要介绍一个 代理主键 是您的选择,但这可能是正确的时机;-)。。。

如果没有,你可以 复制该列 :

1. pk列不区分大小写,不具有特殊字符等等。。。

是的,你会遇到这些角色的问题。离开ASCII总是会引起问题。但当你不仅在英国和美国做生意时,你别无选择。

但是他们强调了自然键作为主键的问题。似乎极有可能有人会编写,例如Muenchen,只是为了稍后将其更改为München,这当然会导致众所周知的PK更新问题。

属性是否是键的一部分与问题无关。

不管 不管是不是钥匙。

是的,为了“正确”编码,并尽可能保证数据不会因为字符集转换问题而损坏,您需要Unicode字符集及其编码之一。

顺便说一句,我确实对桌子本身有一些严重的怀疑。你对德国海德堡和南非海德堡做什么?英国牛津和美国牛津,那里几乎没有一个州没有一个?

什么样的信息取决于那把钥匙?如果根本没有,那么您的表更像是一个“变量类型”,而不是一个“真正的表”。在这种情况下,您最好忘记该表,将cityname属性设置为纯字符串。

如果在从数据库导出数据时确实需要为citynames生成一些“规范拼写”,那么我建议尝试设置一个“语音搜索表”,其中“常用拼写”链接到需要生成的“规范拼写”。但是,希望在填充此类表方面做出认真的努力。

在这种情况下,除了已经提到的Mnchen/Muenchen和Western/Greek字母表问题外,不要忘记Li–ge/Luik/Lttich(Mnchen/Munich)这类问题。

事情改变了他们的名字,或者改变了他们的名字。城市、大学、公园、人们。。所有这些都不适合作为主键。也许是唯一的钥匙?还是唯一密钥的一部分?