在数据库设计中，需要为每一条记录设定key值。key值加上表名，形成了唯一的标志。在面向对象中，唯一标志的方式是使用OID（Object ID），OID用于标识每一个对象。正如ORMapping中的描述的那样，OID的唯一性有三种，具体类中对象标识唯一，类层次中对象标识唯一，所有类的对象标识均唯一。所以OID的唯一性策略可以和映射机制结合起来。在实际中，一般我们都把OID作为数据库中的主键。
简单一点说，OID就是对象的唯一标识。
如何存储OID
OID有几种存储机制：一种是使用自增长字段，但这种方式是由数据库自动控制，虽然方便，但难以对其进行管理，如果需要进行跨数据库的移植，将会成为一个主要问题。另一种存储机制是使用数据库提供的Max函数，在插入新值的时候，先使用Max函数得到新的OID值，再插入数据。这种做法在处理表的键值唯一性时非常有效，但需要对数据库进行短时间的加锁。本案例建议使用键值表的方法对OID进行管理，其基本的思路是，建立一个表，存储了所有表的当前键值，当增加新记录的时候，就从键值表中取出目前的键值，加一作为OID。这种做法的好处是避免的数据表的锁，能够对键值进行集中的控制。在实际的做法中，一般会在内存中对键值进行缓存，以减少键值表上锁带来的性能冲击。使用缓存很将会使OID消耗很快，所以在设计OID时需要考虑OID消耗完的情况。
这种方法可能会因为键值表形成一个性能瓶颈，内存缓冲这个办法听上去不错，但是实际不知道怎么操作。因为内存缓冲会带来另外一个问题就是并发同步的问题。
OID是否与业务相关
OID或是数据库主键是否应该与业务相关呢？这是一个非常具有诱惑力的问题。让OID和业务相关，例如，居民的身份证号，这样做能够省不少事。但是要记住一点，任何的业务都有变化的可能性，身份证就从15位变成了18位，你能够保证他不会有其他的变化吗？而且，如果你严格的遵循OID的思路来进行设计，你会发现，正是和业务不相关的OID设计，能够发挥出非常大的优势，不论是在对象的定位、查询、关联、管理上，都非常的严谨和方便。
呵呵，这个问题我一直有点疑惑。毕竟OID维护起来还是一件非常麻烦的事情。欢迎大家讨论。另外一个问题：OID是使用int类型比较好，还是采用varchar类型比较好？varchar类型的一个好处是分级方便，比如01,01001,01002,02,02001,02002,02003等等。 Scott W. Ambler 先生有对OID使用更为详细的描述： www-900.ibm.com/developerWorks/cn/components/ mapping-to-rdb/index.shtml