在信息系统的开发中，都会涉及到用户与各个信息模块之间的关系。在系统开发设计之初对其规划设计好会给以后的管理等操作带来极大的便利。下面就本人所见的信息系统作一个简单的总结。
一、数据库自动生成 ID 类
这类以用户表设置一个自动增长的数字 ID 为与其他各个信息模块来标识区分的较为常见。还有一类是用户根据 特定的规则＋随机数 来标识 ，这种通常是利用数据库的触发器来完成，在企业内部 OA 系统较为常见，如工号里需要标识出你是哪个部门。第一种其好处是操作起来非常简单；弊病有：某些用户对于 ID 有特殊的需求时改动起来通常比较麻烦；类似于随机数分类不够直观； 第二种情况的好处是可以实现预定义的分类规则，其不好的地方是开发维护起来相对较麻烦，出现错误的时候基本上是无从查起。
二、程序生成 ID 类
这类方式实现用户 ID 与各个系统的关联相对较灵活，可以实现某些规则，维护起来也相对较简单，但所花费的计算机资源相对较多；第二种是生成一串随机数，然后放到用户表的某个字段中，以后的各个系统均与其关联，其好处是对用户隐藏实现细节，不易被仿冒；弊端是用户难以识别。在 .net 下可以用 GUID 来保证，在ASP里有两种方法：
Code
调用方法： strID = GetString( 5 , 4 )
Code
三、用户输入类的关联
此类方法常见的是以用户登录名为线索，各个信息模块均据此与之关联。这类实现方式较好地实现了用户个性化的选择，对用户，对程序设计者都较直观，是一个不错的选择。
以上各种方法中，考虑到删除这种情况，以用户表的自增长ID的关联，系统一旦运行起来，基本上不可能出现重复，其他的实现方法中如删除某个用户而没有删除其各个分支系统的信息，会导致后来注册者看到以前的信息，各种情况根据实际需要权衡。
需要特别注意的是，在整个大的系统中尽量选择使用一种方式实现关联，避免在 A 分支系统中使用自增长ID关联，在B分支系统中使用程序生成ID关联，在C分支系统中又使用用户名关联，这样的后果是整个大系统混乱不堪，给后来者造成了极大的麻烦。
补充：遗漏了在数据库中有个 newid() 函数，它也可以作为内部数据标识的一部分，其实现方法可以是触发器，也可以是放在程序的 SQL 语句中执行。具体的实现因人而异。这个 ID 出现重复的几率和概率相对较小 。