qq聊天纪录----------码生成器只简单的处理了第一个主键和字段

转载 2007年09月18日 16:42:00

   用户22069951被创建者(123156272)批准加入本群。

   交谈中请勿轻信汇款、中奖消息,勿轻易拨打陌生电话。

齐步走(22069951) 2007-09-18 11:44:05
报个到哈
齐步走(22069951) 2007-09-18 12:06:55
怎么没有人说话、
rik(32145628) 2007-09-18 12:11:23
午饭时间
齐步走(22069951) 14:46:59
天生天养兄,你好,看了你做的这个SocanCode代码生成器很是佩服,难得你有时间和耐心做出个这么好用工具,但玉无完玉,人无完人,我最近计划用这个工具生成一个新的项目,发现用这个工具生成的DAL代码和存储过程不能符合要求,分析一下,原来是这个代码生成工具处理数据库中的主键有问题,众所周知,操作数据库中表的数据一般都是根据表的主键来更新和删除数据。有些表有多个主键,那更新和删除数据时就得根据多个主键来操作;Identifier字段一般都做为主键存在,这一类型的表用SocanCode代码生成器生成的代码是没有问题的,但有些表是不用Identifier字段做主键,有些表也没有Identifier字段,这些情况SocanCode代码生成器只简单的处理了第一个主键和字段,所以生成的代码有问题,能不能先根据先主键来生成代码,并且考虑生成多个主键的情况,在没有主键的情况下考虑Identifier字段,即没有主键也没有Identifier字段的表考虑用所有字段做为主键,这种处理方式也符合数据库的一般操作方式,还有GetMaxID()并不都是int类型,如果只有一个主键就根据这个主键的类型生成GetMaxKey()函数,多个主键的就没有必要生成GetMaxKey函数了,在增加数据时也没有必要主键自动加一,目前只研究了这些,望天生天养兄斧正,放在这也希望大家讨论一下
玴ブゅ(9612459) 14:49:39
联合主键的情况确要考虑!!!
玴ブゅ(9612459) 14:49:53
我也要用这个,只不过现在还没用到!
ぱぱ(7581276) 14:50:29
自动代码能完成90%的工作量,有些特殊的还是要自己写的
ぱネぱ緄(123156272) 14:50:44
Delete(int key1,guid key2)这样子多参数的方法?
玴ブゅ(9612459) 14:50:48
嗯,特殊的东西是要自己手写
ぱネぱ緄(123156272) 14:51:38
如果主键单一,建议先去除Identity,待生成代码,再加上无烦
ぱぱ(7581276) 14:53:06
另外,可以在设计数据库的时候,尽量用单一主鍵,实在不行的话,用代码生成器生成一部分,再手动改改
ぱぱ(7581276) 14:53:11
效果也不错
ぱネぱ緄(123156272) 15:05:47
数据库主键设计之思考 

在我们的数据库设计中,不可逃避的就是数据库表的主键,可能有很多朋友没有深入思考过,主键的设计对整个数据库的设计影响很大,因此我们不得不要重视起来。 

主键的必要性: 

有些朋友可能不提倡数据库表必须要主键,但在我的思考中,觉得每个表都应该具有主键,不管是单主键还是双主键,主键的存在就代表着表结构的完整性,表的记录必须得有唯一区分的字段,主键主要是用于其他表的外键关联,本记录的修改与删除,当我们没有主键时,这些操作会变的非常麻烦。 

主键的无意义性: 

我强调主键不应该具有实际的意义,这可能对于一些朋友来说不太认同,比如订单表吧,会有“订单编号”字段,而这个字段呢在业务实际中本身就是应该具有唯一性,具有唯一标识记录的功能,但我是不推荐采用订单编号字段作为主键的,因为具有实际意义的字段,具有“意义更改”的可能性,比如订单编号在刚开始的时候我们一切顺利,后来客户说“订单可以作废,并重新生成订单,而且订单号要保持原订单号一致”,这样原来的主键就面临危险了。因此,具有唯一性的实际字段也代表可以作为主键。因此,我推荐是新设一个字段专门用为主键,此主键本身在业务逻辑上不体现,不具有实际意义。而这种主键在一定程序增加了复杂度,所以要视实际系统的规模大小而定,对于小项目,以后扩展不会很大的话,也查允许用实际唯一的字段作主键的。 

主键的选择 

    我们现在在思考一下,应该采用什么来作表的主键比较合理,申明一下,主键的设计没有一个定论,各人有各人的方法,哪怕同一个,在不同的项目中,也会采用不同的主键设计原则。 

第一:编号作主键 

     此方法就是采用实际业务中的唯一字段的“编号”作为主键设计,这在小型的项目中是推荐这样做的,因为这可以使项目比较简单化,但在使用中却可能带来一些麻烦,比如要进行“编号修改”时,可能要涉及到很多相关联的其他表,就象黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”,我们再那么先知,都无法知道业务将会修改成什么? 

第二:自动编号主键 

      这种方法也是很多朋友在使用的,就是新建一个ID字段,自动增长,非常方便也满足主键的原则,优点是:数据库自动编号,速度快,而且是增量增长,聚集型主键按顺序存放,对于检索非常有利;数字型的,占用空间小,易排序,在程序中传递也方便;如果通过非系统增加记录(比如手动录入,或是用其他工具直接在表里插入新记录,或老系统数据导入)时,非常方便,不用担心主键重复问题。 

      缺点:其实缺点也就是来自其优点,就是因为自动增长,在手动要插入指定ID的记录时会显得麻烦,尤其是当系统与其他系统集成时,需要数据导入时,很难保证原系统的ID不发生主键冲突(前提是老系统也是数字型的);如果其他系统主键不是数字型那就麻烦更大了,会导致修改主键数据类型了,这也会导致其他相关表的修改,后果同样很严重;就算其他系统也是数字型的,在导入时,为了区分新老数据,可能想在老数据主键前统一加一个“o”(old)来表示这是老数据,那么自动增长的数字型又面临一个挑战。 

第三:Max加一 

     由于自动编号存在那些问题,所以有些朋友就采用自己生成,同样是数字型的,只是把自动增长去掉了,采用在Insert时,读取Max值后加一,这种方法可以避免自动编号的问题,但也存在一个效率问题,如果记录非常大的话,那么Max()也会影响效率的;更严重的是并发性问题,如果同时有两人读到相同的Max后,加一后插入的ID值会重复,这已经是有经验教训的了。 

第四:自制加一 

     考虑Max加一的效率后,有人采用自制加一,也就是建一个特别的表,字段为:表名,当前序列值。这样在往表中插入值时,先从此表中找到相应表的最大值后加一,进行插入,有人可能发现,也可能会存在并发处理,这个并发处理,我们可以采用lock线程的方式来避免,在生成此值的时,先Lock,取到值以后,再unLock出来,这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题:在与其他系统集成时,脱离了系统中的生成方法后,很麻烦保证自制表中的最大值与导入后的保持一致,而且数字型都存在上面讲到的“o”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的,应该字符型主键可以应付很多我们意想不到的情况。 

第五:GUID主键 

    目前一个比较好的主键是采用GUID,当然我是推荐主键还是字符型的,但值由GUID生成,GUID是可以自动生成,也可以程序生成,而且键值不可能重复,可以解决系统集成问题,几个系统的GUID值导到一起时,也不会发生重复,就算有“o”老数据也可以区分,而且效率很高,在.NET里可以直接使用System.Guid.NewGuid()进行生成,在SQL里也可以使用 NewID()生成。优点是: 

同 IDENTITY 列相比,uniqueidentifier 列可以通过 NewID() 函数提前得知新增加的行 ID,为应用程序的后续处理提供了很大方便。 

便于数据库移植,其它数据库中并不一定具有 IDENTITY 列,而 Guid 列可以作为字符型列转换到其它数据库中,同时将应用程序中产生的 GUID 值存入数据库,它不会对原有数据带来影响。 

便于数据库初始化,如果应用程序要加载一些初始数据, IDENTITY 列的处理方式就比较麻烦,而 uniqueidentifier 列则无需任何处理,直接用 T-SQL 加载即可。 

便于对某些对象或常量进行永久标识,如类的 ClassID,对象的实例标识,UDDI 中的联系人、服务接口、tModel标识定义等。 

缺点是: 

GUID 值较长,不容易记忆和输入,而且这个值是随机、无顺序的 

GUID 的值有 16 个字节,与其它那些诸如 4 字节的整数相比要相对大一些。这意味着如果在数据库中使用 uniqueidentifier 键,可能会带来两方面的消极影响:存储空间增大;索引时间较慢。 

  

我也不是推荐GUID最好,其实在不同的情况,我们都可以采用上面的某一种方式,思考了一些利与弊,也方便大家在进行设计时参考。这些也只是我的一点思考而已,而且可能我知识面限制,会有一些误论在里面,希望大家有什么想法欢迎讨论。 


ぱネぱ緄(123156272) 15:09:41
这是N久以前网上看的一篇文章,如果一个表没主键,或多个主键都是不合适的,代码生成器兼容这些不规范的东西,相当于纵容了数据库设计者的错误.太智能的的代码生成器,会让无数人不经过思考就使用,既然生成成功了就会根本不想去读懂生成的代码了
玴ブゅ(9612459) 15:12:03
联合主键用得是比较多的!
Elwin(36012201) 15:13:22
中秋将至赠群友

房子几时有
把酒问群友
不知群里姑娘 可有男朋友
我欲离群而去 又恐机会错失
夜难眠 不应有醉 何时才能把梦圆
女有黑白美丑
男有高矮肥瘦
此事古难全
但愿群长久 光棍不再有
ぱネぱ緄(123156272) 15:15:20
刚刚用codematic试了一下生成有两个主键的表,一个Id,一个Id2,生成的存储过程用Id为主键了,而代码又以Id2为主键,可见李天平也是没有考虑兼容这些不好的数据库设计的.所以特殊情况非用不可,还是手动改
ぱネぱ緄(123156272) 15:18:35
再测试标识键不是主键的情况,发现comdematic也是自动以标识为主键的
玴ブゅ(9612459) 15:18:51
别看着李天平来搞!只能参考参考
齐步走(22069951) 15:19:19
不晓得大家用过这个没有Blue Sky .Net Code Generator,我觉得可以参考一下
ぱぱ(7581276) 15:20:19
我用过,每次用都要联网,
ぱぱ(7581276) 15:20:24
不敢用了
齐步走(22069951) 15:28:34
那还是用CodeSmith算了,想怎么搞就怎么搞
 

关于自定义代码生成器(续)---SQL2008查询数据库字段主键,外键,唯一键等相关属性

2. 查询字段名,表名,架构名,序号,是否主键,是否外键,是否唯一键,是否为空,是否自动增长,默认值,字段类型,大小,长度,小数位数,相关属性select a.*,isnull(b.rtable,'0...
  • nlx0201
  • nlx0201
  • 2013年01月24日 14:05
  • 1531

SQL 数据库 学习 007 通过一个示例简单介绍什么是字段、属性、列、元组、记录、表、主键、外键

我们来介绍一下:数据库是如何存储数据的。数据库是如何存储数据的来看一个小例子现在,假如我们现在想存储 员工的信息。也就是说:我们来通过这个例子来看看 字段、记录、表 是一个什么东西。我们下面通过存储一...

第一个免杀花指令生成器--不简单的免杀工具(图)

第一个免杀花指令生成器--不简单的免杀工具(图) 陆续将以前发表在杂志的文章放上来~,发表于《黑客X档案》,第几期忘了,呵呵 前言 相信做过免杀的朋友都知道花指令吧。加花指令...
  • zhu2695
  • zhu2695
  • 2013年11月18日 13:20
  • 1886

QQ在线状态纪录源码

  • 2012年10月02日 13:51
  • 863KB
  • 下载

MyBatis主键生成器Jdbc3KeyGenerator(二)

上一篇博客MyBatis主键生成器KeyGenerator(一)中我们大体介绍了主键生成器的接口及配置等,接下来我们介绍一下KeyGenerator的实现类Jdbc3KeyGenerator Jdbc...

主键生成器MSSQLSERVER

  • 2007年08月21日 22:23
  • 2KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:qq聊天纪录----------码生成器只简单的处理了第一个主键和字段
举报原因:
原因补充:

(最多只允许输入30个字)