我正在开发一个支持Oracle,Sql Server和Informix作为数据存储库的应用程序(.Net).Informix的一个问题是一个表(这是遗留的东西)有一个2048个字符的主键,而Informix不允许这个宽度的PK.因此,我的初始解决方案是让应用程序从键值派生MD5值,并在插入或查找数据时将其用作主键.好吧,这有效,但让我立即"升级"现有数据库中的数据问题,由于各种原因必须通过Sql脚本完成.遗憾的是,Informix没有内置的MD5功能,因此我很难编写一个Sql脚本来创建新的PK列并从现有数据中填充它.
所以我的问题是:任何人都可以建议一种更好的方法来显着压缩长字符串值,这样可以避免这个问题吗？
您的方法存在缺陷,因为PK必须是唯一的定义,并且MD5可能会产生冲突(重复).
而是考虑使用代理PK(例如身份或GUID).
任何人都可以建议一个更好的方法来显着压缩长字符串值,这将避免这个问题
根据定义,您无法压缩任意字符串并保持唯一性.显然,如果字符串具有您所知道的某种结构,您可以使用此知识来创建特定于应用程序的压缩算法.
回应评论:
我也有代理键的问题,它与存储的日期没有关系 - 糟糕的数据库设计
我知道代理vs自然键是一个有争议的主题,但你提出的MD5哈希肯定是一个代理键？并且在任何情况下"所有设计都需要权衡",因此如果没有某些上下文,我不会将数据库设计描述为"糟糕".恕我直言,如果没有短于2048个字符的自然键,代理键可能是一个不错的选择.
还需要考虑性能权衡:使用MD5或GUID代理PK,您有可能进行页面拆分,因为新行将插入到表的中间,而在末尾插入Identity PK.
按什么定义？
关键词是"任意的".诸如ZIP之类的无损压缩算法并不能保证在所有输入上实现给定的压缩比 - 考虑尝试ZIP压缩ZIP存档.