| « | August 2026 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:
日志总数:2
评论数量:0
留言数量:0
访问次数:19203
建立时间:2005年3月14日 |
| |
|
 oid
网上资源
tangttang 发表于 2005/3/14 14:49:17 |
|
OID是什么在数据库设计中，需要为每一条记录设定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 |
|
|