发信人: rational()
整理人: majorsun(2000-03-07 19:19:50), 站内信件
|
实体标识是采用无意义序列码好还是有意义的组合关键字？
最低满足要求：实体唯一性、关系清晰性
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.106.33]
发信人: haotongzhi (Haotongzhi), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Thu Aug 5 18:44:01 1999), 站内信件
【 在 rational (2pc) 的大作中提到: 】
: 实体标识是采用无意义序列码好还是有意义的组合关键字？
: 最低满足要求：实体唯一性、关系清晰性
我总是两者皆用。
比如员工标识，你用序列号时，总有客户不满意，喜欢编“有意义”
的代码，而且时常要改（这更要命），所以，数据库自身的关联
采用ID，而又提供代码给用户，这样会麻烦一些，但功能上就强
很多。
--
※ 修改:．haotongzhi 于 Aug 5 18:44:44 修改本文．[FROM: 202.104.161.229]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.161.229]
发信人: rational (HardWork), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Thu Aug 5 18:51:14 1999), 站内信件
1.你的意思是primarykey 不能改动吗？
2.请问到底是用序号还是有意义的东西做物理上的唯一标志？
如果用序号如何保证逻辑上的唯一性（特别是大量数据）
如果用序号+有意义又如何保证逻辑上的唯一性
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.106.33]
发信人: haotongzhi (Haotongzhi), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Thu Aug 5 19:28:43 1999), 站内信件
【 在 rational (HardWork) 的大作中提到: 】
: 1.你的意思是primarykey 不能改动吗？
: 2.请问到底是用序号还是有意义的东西做物理上的唯一标志？
: 如果用序号如何保证逻辑上的唯一性（特别是大量数据）
: 如果用序号+有意义又如何保证逻辑上的唯一性
: .......
我觉得最好使用不改动的字段作为唯一标识，又要留意是否可
以重用等问题。
这个问题是很有趣的，就是在primary key之外如果还有
uniq，并且用户把它看作实体的标识，是否容许改动呢？
当实体是关联的，不特意建立一个列做标识就要用组合的关键
字时，这个问题更有意思，我也很希望听听大家的看法。
使用序号最好使用程序自身提供的ID，也可以自己写一个不重复
编号的生成器。它们只是表明记录的唯一性。绝对的标识是有疑
问的：
如果给张三的所有记录，都改成李四的，那么原来张三的
“标识”到底标识张三还是李四？
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.161.229]
发信人: dobby (印子), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Thu Aug 5 21:33:30 1999), 站内信件
【 在 rational (2pc) 的大作中提到: 】
: 实体标识是采用无意义序列码好还是有意义的组合关键字？
: 最低满足要求：实体唯一性、关系清晰性
一个实体没有实际的primary key的可能性不大，如果出现这种情况，
还是实体的选择出了问题。
如果你的目标数据库是sybase，建议不用identity属性，
当你把数据从里面select into到另一表时，它的数值
会改变，而且有时会出现一大段断号。
自己做一个小表来管理这些无意义的序列码比较好。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.148.136]
发信人: kamkam (Xman), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易 BBS (Fri Aug 6 03:02:57 1999), 转信
: 会改变，而且有时会出现一大段断号。
: 自己做一个小表来管理这些无意义的序列码比较好。
:
这个问题困扰过我们很久，原来使用有意义的字段组合作为
primary key ，业务一改动，可能就造成表需要重新寻找关键字，非常头痛
后来使用identity列作为关键字基本解决业务变化频繁的问题，但又引入新的问题
1。使用identity列，每个新插入的记录都是紧挨着的，多用户连接时，死琐严重，
后来对该列使用非聚蔟，并对表分区，情况有所改观，但问题没有彻底解决
2。几个关键表都通过identity列关联，一旦列溢出，处理麻烦
自己另外建一个发号表来管理可以解决问题，但同样面临废号回收的处理。
选用主键其实是很基础的问题，但我觉得我们现在都还有很多争论，也许还是经验不足
吧。你提出的实体应该有唯一主键，否则就是实体划分出了问题的说法当然正确，
然而在情况经常变化的时候，就很让人头疼，你是修改数据结构呢还是不改？
不幸这正是我们面临的情况。
btw
in sybase , u can "set identity_insert table_name on" to set identity column's
value by yourself , not by server.
if u use NT , if u close Nt without shutdown sybase server in control panel,
u will get uncontinue value of identity column . Avoid this , shutdown sybase
before close NT server . u can 'set identity factor '(sth like that , use
sp_configure to get detail) command to reduce the number abondom by sybase
server
--
※ 来源:．网易 BBS bbs.netease.com．[FROM: ppp160.zhongshan.gd.]
发信人: haotongzhi (Haotongzhi), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Fri Aug 6 08:15:52 1999), 站内信件
【 在 kamkam (Xman) 的大作中提到: 】
: : 会改变，而且有时会出现一大段断号。
: : 自己做一个小表来管理这些无意义的序列码比较好。
: 这个问题困扰过我们很久，原来使用有意义的字段组合作为
: primary key ，业务一改动，可能就造成表需要重新寻找关键字，非常头痛
: ......
.
适应业务的变化，正是现在开发企业软件最具挑战性的问题，常常也是
成败的关键，所以虽然数据库自动维护的ID有种种坏处，我还是坚持用
ID做PRIMARY KEY，（用自己写的好不了多少）让用户有改变较大改动
的能力，但簇索引则总是放在“有意义”的UNIQ索引上。
前一位朋友提到的自动ID的问题，我也正在头痛，就是当需要建立分布
式的应用时，用ID带来的麻烦。我的一个客户要求两边都能更新，但两
边暂时没有有效的连通手段，不知几位有何良策？
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.161.229]
发信人: majorsun (major), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易 BBS (Fri Aug 6 08:46:57 1999), 转信
对于PID，我是这样处理的：
1/ 所有ID为同长度无意义的序列号。（如果是数字型的，右对齐原则
左边视为补0）
2/ ID的结构是-- 分组号1+分组号2+……+分组号N+定义号
分组号由上级的授权机构给出，但是分组号仅仅是分组而已，
没有固定的意义，这样远程授权就比较简单。这样的结构有点象
电话号码 752-102-3481 。定义号当然就是自动的序列号而已。
具体的定义程序要先获得授权的分组号，然后……
这样对于废号的处理多半在本地就完成了。
当此组容量到达溢出阈值时，申请新的分组号。不过，系统要维护
一张分组授权含义表，而且分组号不可避免地带有实体的实际特征分类
的特质。只是同一特征的实体的分组号不一定是相同或连续的。
同样是电话号码的例子，国内的要求同一地区的地区号是一致的，
所以经常看见地区号码升位。而无意义分组是先限定总长度，
再根据地区需要增加分区号码。好像美国的电话号码有点类似？
3/ 在实际应用中，内部计算采用PID，配合分组授权含义表，可以满足
一般需要了。而输入、查询等功能的人机对话部分，采用输入码。
这就和我们处理汉字输入的概念一样。内部都是区位码，外部就可以
万码奔腾。而且同一系统、同一子系统都可以对同一PID拥有不同的
输入码。不过这会很辛苦，要写不少罗罗嗦嗦的输入程序。
--
落英缤纷 拈花微笑
※ 来源:．网易 BBS bbs.netease.com．[FROM: 202.103.161.122]
发信人: haotongzhi (Haotongzhi), 信区: SystemAnalysis
标 题: Re: 请讨论如下数据库建模的一个小问题！
发信站: 网易虚拟社区 (Sat Aug 7 08:16:06 1999), 站内信件
【 在 majorsun (major) 的大作中提到: 】
: 对于PID，我是这样处理的：
: 1/ 所有ID为同长度无意义的序列号。（如果是数字型的，右对齐原则
: 左边视为补0）
: 2/ ID的结构是-- 分组号1+分组号2+……+分组号N+定义号
: .......
这个方法大概是属于比较“专业”的那一类，我观察国外的一些系统也
是采用类似的方案，但的确是很“累”的做法，不过要真想另整个系统
有一个比较完善的解决方案，可能是偷不到懒的。
我原来采用过分段编码的方法，但maior所说方法中“分组就是分组”，
“溢出再申请新组”，没曾试过，很有价值，谢谢！
--
※ 修改:．haotongzhi 于 Aug 7 08:23:54 修改本文．[FROM: 202.104.161.229]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.161.229]
|
|