浏览 2079 次
锁定老帖子 主题:实体类设计有关key的一些想法
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-04-01
最后修改:2011-06-18
基本上key分为对人有意义和对人无意义。 对人有意义的key值应该由用户输入,或者从其他地方得到。对人无意义的key应该由系统生成,一般为uuid或者流水号,这里有一个值得注意的地方,即使无意义的key是系统范围唯一的,也不应该作为数据库的主键。 对于一个实体,一个key可以标识它,而这个实体其他部分可以根据语义做一定的聚合然后和key关联起来。 举个例子,对一个商品建模,有一个key标识它,对于商品物理方面的属性,我们可以定义一个类,包括商品的重量,体积,等等,对于商品商业方面的属性,我们可以定义一个类,包括商品的成本,价格等等。当然以上的类中都包括一个字段即商品key。 这样的话,当客户端查询一个实体时,只需要得到这个实体一部分的属性即可,降低了一些后台开销,传递的东西也都是客户感兴趣的东西。 大家以为如何。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-04-01
zhang_xzhi_xjtu 写道 这里有一个值得注意的地方,即使无意义的key是系统范围唯一的,也不应该作为数据库的主键
为什么要在系统范围内唯一,而不是该实体域内唯一,也就是该库表唯一呢? ----------------------- 权限管理圈子欢迎您加入: http://accessmanager.group.iteye.com/ |
|
返回顶楼 | |
发表时间:2009-04-02
业务库设计的垃圾以后搞综合库,主题库的时候麻烦就是了.如果只是为了挣钱实用就行,什么数据库设计范式.统统没有用.快速开发快速验收才是王道.技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.一句话 一个商务等于十个技术.最近才领悟到的.百行代码不如一句忽悠,简单一个数据库查询写文件的小工具商务一说就是什么高深的数据整合系统了.立马身价大增.
|
|
返回顶楼 | |
发表时间:2009-04-02
[img][/img] fjlyxx 写道
业务库设计的垃圾以后搞综合库,主题库的时候麻烦就是了.如果只是为了挣钱实用就行,什么数据库设计范式.统统没有用.快速开发快速验收才是王道.技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.一句话 一个商务等于十个技术.最近才领悟到的.百行代码不如一句忽悠,简单一个数据库查询写文件的小工具商务一说就是什么高深的数据整合系统了.立马身价大增.
引用
技术能解决的问题就不是问题了,技术人员能考虑到的问题也都不是问题.
|
|
返回顶楼 | |
发表时间:2009-04-02
最后修改:2009-04-03
为什么要在系统范围内唯一,而不是该实体域内唯一,也就是该库表唯一呢?
|
|
返回顶楼 | |
发表时间:2009-04-02
metadmin 写道 为什么要在系统范围内唯一,而不是该实体域内唯一,也就是该库表唯一呢?
----------------------- 权限管理圈子欢迎您加入: http://accessmanager.group.iteye.com/ 这只是一个假设,说明即使这样,也不要在数据库里用. 这里强调的是逻辑的key和数据库的key的分离. |
|
返回顶楼 | |
发表时间:2009-04-03
我一般有一个逻辑的KEY(系统生成,用作表间关联:uuid)和一个实际的ID(实体标识:unique)
|
|
返回顶楼 | |