如何最好地降低主键值？

Question

我正在开发一个支持Oracle，Sql Server和Informix作为数据存储库的应用程序（.Net）。 Informix的一个问题是一个表（这是遗留的东西）有一个2048个字符的主键，而Informix不允许这个宽度的PK。因此，我的初始解决方案是让应用程序从键值派生MD5值，并在插入或查找数据时将其用作主键。好吧，这有效，但让我立即“升级”现有数据库中的数据问题，由于各种原因必须通过Sql脚本完成。可悲的是，Informix没有内置的MD5功能，所以我很难编写一个Sql脚本来创建新的PK列并从现有数据中填充它。

所以我的问题是：有人能建议一种更好的方法来显着压缩长字符串值，这样可以避免这个问题吗？

Answer 1

您的方法存在缺陷，因为PK必须是唯一的定义，并且MD5可能会产生冲突（重复）。

相反，请考虑使用代理PK（例如身份或GUID）。

  

任何人都可以建议一种更好的方法来显着压缩长字符串值，这样可以避免这个问题

根据定义，您无法压缩任意字符串并保持唯一性。显然，如果字符串具有您所知道的某种结构，您可以使用此知识来创建特定于应用程序的压缩算法。

回应评论：

  

我也有代理键的问题，这与存储的日期没有关系 - 糟糕的数据库设计

我知道代理vs自然键是一个有争议的主题，但你提出的MD5哈希肯定是一个代理键？在任何情况下“所有设计都需要权衡”，所以如果没有一些上下文，我就不会将数据库设计描述为“糟糕”。恕我直言，如果没有 自然密钥短于2048个字符，代理密钥可能是一个不错的选择。

还需要考虑性能权衡：使用MD5或GUID代理PK，您有可能进行页面拆分，因为新行将插入到表的中间，而在末尾插入Identity PK。

  

按什么定义？

关键词是'任意'。 ZIP等无损压缩算法无法保证在所有输入上实现给定的压缩比 - 考虑尝试ZIP压缩ZIP存档。

Answer 2

在Informix中，如果您创建一个具有较大页面大小的dbspace（您需要使用12,14或16个KiB页面），则可以在该dbspace中创建最大约3 KiB的键索引（经验法则， 5个键值必须适合一个索引页面。）

但一个关键的大可能不是很有效，对它有礼貌。我很想知道PK中列的细分以及为什么它们必须如此之大以至于它们加起来为2 KiB。你能不能使用某种替代品吗？

Answer 3

我认为你可以将键分成两部分并将这些部分存储在两列中，例如“id1”，“id2”。然后您可以创建复合主键。