在大多数利用数据库的管理信息系统中，涉及到人员资料管理的时候，多数会记录身份证信息，而且身份证号码往往被作为所在表的关键字段（主键、外键、惟一索引等）使用，用以检索相关业务的惟一性，因此，对这类信息系统而言，身份证号码惟一的重要性不言而喻。在我国，1999年以前使用的是15位的身份证，而1999年后，对身份证进行了升位，由15位变为18位。升位的规则是将15位身份证中的年份代码由2位升级为4位，并在尾部增加一位校验码。对相当多的信息系统而言，身份证升位后，面临一个类似的技术需求，即如何处理这两种身份证号码的惟一性。也就是说，每个15位号码有一个对应的18位号码，虽然在数据库层两个号码不重复，但是在业务上，两个号码是一致的。

    从技术实现的角度来看，最好的解决方案是一次性将系统中的所有15位身份证转换为18位身份证，以后全部使用18位身份证号码办理业务。而根据18位身份证号码的规则，其实现手段并不复杂。但是放到业务层面，很多信息系统并不允许这样做，以电子档案系统为例，大多数业务都要求系统内的数据需如实反映纸质档案的原始情况，除非纸质档案发生改变。笔者在以前实施过的一个房地产档案管理系统中，就遇到这类业务要求。对于房地产权属证明书中的权属人资料，必须以原有纸质档案文件中的号码为准。而当市民利用18位身份证号码去办理业务的时候，系统又需要能找出其原有15位身份证所对应的业务信息。因此，当业务上需要同时在数据库中保留两种格式的身份证，同时又必须在业务上判断惟一性的时候，技术处理的手段就非常重要了，目前，绝大多数的系统都是采用客户机/服务器模式，因此，很多系统将身份证转换的处理放到了客户机上实现。

    在客户机上实现这种功能无疑会带来系统的复杂性，以在一个数据表（假设为TableA）中判断身份证字段（假设为ID）是否存在某一个号码id为例，客户机程序首先需要将号码id转为两个版本的身份证号码：id15，id18，然后用以下逻辑判断数据表中是否存在这个号码：

    另外一种解决思路是在服务器端（例如在数据库层）完成转换。利用数据库的自定义函数功能，开发者按照身份证的号码转换规则编写自定义函数实现该功能，使得在数据库一级支持身份证的号码转换。由于大多数关系型数据库都支持扩展的结构化查询语言（SQL），可利用这些语句创建自定义的函数或存储过程^[1]。但是，SQL的语法较为简单，且支持的内部变量的数据类型较少（例如，不支持数组及其操作），操作数据表效率尚可，对于复杂的算术及逻辑运算的支持能力就较差，强行要实现，程序的效率也会十分低下。

    但是从效率的角度来看，在数据库层实现身份证号码转换的思路无疑比在客户端实现要好，关键是如何提高数据库层实现的灵活性及效率。在应用中，我们发现，大多数关系型数据库都支持外部的功能扩展，以在国内信息系统中使用最为普遍的关系数据库MS SQLServer为例，不仅支持外部存储过程的扩展方式，还支持OLE自动化方式的扩展，因此，本文介绍用一个用VB实现的身份证Active组件，然后利用SQLServer对OLE自动化技术的支持，将该组件改造为一组SQLServer上的自定义函数，以实现数据库层面的身份证号码转换。本文的实现适用于MS SQLServer 2000以后的所有版本。

    在我国，身份证存在两个版本，早期的15位长，称为第一代身份证，现在使用的是第二代身份证，18位长，根据1999年公布的中华人民共和国国家标准GB11643-1999中有关身份证号码的规定，第二代身份证号码是特征组合码，由17位数字本体码和1位数字校验码组成^[2]，两代身份证之间的结构及差别主要反映在出身日期码的长度及数字校验码上，假设一个出生于1982年1月1日，户口所在地在广州市天河区的男性公民，其两代身份证号码的结构可能如图1所示。