背景
通常,在对遗留应用程序进行建模时,架构师的重要任务之一就是要充分利用数据库的存储功能。 大多数旧版应用程序在开发时都会受到可用技术的限制,因此,根据当前情况并不是最佳的。 其中一种情况是CHAR字段的广泛使用,这对于当前的空间存储而言并不是最佳解决方案。 本文将重点介绍在DB2 for iSeries中将CHAR数据字段转换为VARCHAR时需要采取的系统方法。
问题陈述
CHAR数据类型的基本约束是它缺乏灵活性,无法获得存储所需的最佳空间。 CHAR(50)字段将在数据库中保留50个字节,而不管该字段的数据内容如何。 如果此字段的大多数值小于长度35,则剩余的15个字节将浪费大量空间,否则数据库将无法利用它。 这将导致额外的磁盘空间。
解
在这种情况下,节省存储空间的最重要和最直接的选择之一就是让数据库仅存储相关数据而没有不必要的尾随空间。 为此,架构师只需将CHAR字段转换为VARCHAR。
这真的是解决方案吗?
只需将所有CHAR列都转换为VARCHAR是合适的解决方案,否则,什么是最佳方法? 这就是真正的陷阱所在,而忽略了可能导致性能下降的问题,这在以后的阶段将很难跟踪。
理想情况下,这是一个两步过程:
(a)标识要转换的相关列:将所有列从CHAR盲目更改为VARCHAR可能会付出巨大的努力,因为不仅需要相应地更改表定义,而且还要相应地更改插入/更新/删除这些列的相关程序。 因此,仅应选择节省空间很大的那些列。 请参考“建筑师建议”部分以选择适当的列。
(b)将已识别列和相关程序的数据定义从CHAR转换为VARCHAR:这将需要对iSeries上的DB2如何实现VARCHAR的存储有一点了解。 请参考下面的“在DB2(iSeries)中实现VARCHAR存储”部分。
在DB2(iSeries)中实现VARCHAR存储
可变长度列(VARCHAR)支持使您可以将表中任意数量的列定义为可变长度。 如果使用VARCHAR支持,通常可以减少表的大小。 可变长度列中的数据在内部存储在两个区域中:固定长度或ALLOCATE区域和溢出区域。 ALLOCATE区域的行为与CHAR数据类型的行为类似,即,不管实际数据长度如何,数据库保留的存储字节数与分配区域中指定的字节数相同。 任何超出此长度的数据都将存储在变量或溢出区中。 如果指定了默认值,则分配的长度至少与该值一样大。
给建筑师的建议
以下几点可帮助您确定