实体类设计有关key的一些想法

在实体类中一般都有一个key来引用这个实体，在具体设计中，这个key对实体设计是有一定影响的。

基本上key分为对人有意义和对人无意义。

对人有意义的key值应该由用户输入，或者从其他地方得到。对人无意义的key应该由系统生成，一般为uuid或者流水号，这里有一个值得注意的地方，即使无意义的key是系统范围唯一的，也不应该作为数据库的主键。

对于一个实体，一个key可以标识它，而这个实体其他部分可以根据语义做一定的聚合然后和key关联起来。

举个例子，对一个商品建模，有一个key标识它，对于商品物理方面的属性，我们可以定义一个类，包括商品的重量，体积，等等，对于商品商业方面的属性，我们可以定义一个类，包括商品的成本，价格等等。当然以上的类中都包括一个字段即商品key。

这样的话，当客户端查询一个实体时，只需要得到这个实体一部分的属性即可，降低了一些后台开销，传递的东西也都是客户感兴趣的东西。

大家以为如何。

评论

6 楼 hszdz 2009-04-03  

我一般有一个逻辑的KEY（系统生成,用作表间关联：uuid）和一个实际的ID（实体标识：unique）

5 楼 zhang_xzhi_xjtu 2009-04-02  

metadmin 写道

为什么要在系统范围内唯一，而不是该实体域内唯一，也就是该库表唯一呢？

-----------------------
权限管理圈子欢迎您加入：
http://accessmanager.group.iteye.com/

这只是一个假设,说明即使这样,也不要在数据库里用.
这里强调的是逻辑的key和数据库的key的分离.

4 楼 metadmin 2009-04-02  

为什么要在系统范围内唯一，而不是该实体域内唯一，也就是该库表唯一呢？

3 楼 zhang_xzhi_xjtu 2009-04-02  

<p>[img][/img]</p>
<div class="quote_title">fjlyxx 写道</div>
<div class="quote_div">   业务库设计的垃圾以后搞综合库,主题库的时候麻烦就是了.如果只是为了挣钱实用就行,什么数据库设计范式.统统没有用.快速开发快速验收才是王道.技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.一句话 一个商务等于十个技术.最近才领悟到的.百行代码不如一句忽悠,简单一个数据库查询写文件的小工具商务一说就是什么高深的数据整合系统了.立马身价大增.</div>
<p><br /><br />短期的看也许这样是对的,但是公司长远的发展如果也是这么想的话,就不太好了. 当然,中国有中国的国情. <br />但是一个技术人员,还是应该想着怎么在技术上做的比较好. <br /></p>
<div class="quote_title">引用</div>
<div class="quote_div">技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.</div>
<p><br /><br /><br />从任何从业者的角度看,我们不应该自己不尊重自己的职业. 而且技术问题也并没有想象中那么简单. <br /><br />比如开发一个好的操作系统就是一个技术问题. <br />领导一个公司走向成功对领导而言也是一个技术问题.</p>
<p> </p>

2 楼 fjlyxx 2009-04-02  

   业务库设计的垃圾以后搞综合库,主题库的时候麻烦就是了.如果只是为了挣钱实用就行,什么数据库设计范式.统统没有用.快速开发快速验收才是王道.技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.一句话 一个商务等于十个技术.最近才领悟到的.百行代码不如一句忽悠,简单一个数据库查询写文件的小工具商务一说就是什么高深的数据整合系统了.立马身价大增.

1 楼 metadmin 2009-04-01  

zhang_xzhi_xjtu 写道

这里有一个值得注意的地方，即使无意义的key是系统范围唯一的，也不应该作为数据库的主键

为什么要在系统范围内唯一，而不是该实体域内唯一，也就是该库表唯一呢？

-----------------------
权限管理圈子欢迎您加入：
http://accessmanager.group.iteye.com/