数据表设计的中对主键、索引的思考

上传人:鲁** 文档编号:485489851 上传时间:2023-01-28 格式:DOC 页数:7 大小:195.01KB
返回 下载 相关 举报
数据表设计的中对主键、索引的思考_第1页
第1页 / 共7页
数据表设计的中对主键、索引的思考_第2页
第2页 / 共7页
数据表设计的中对主键、索引的思考_第3页
第3页 / 共7页
数据表设计的中对主键、索引的思考_第4页
第4页 / 共7页
数据表设计的中对主键、索引的思考_第5页
第5页 / 共7页
点击查看更多>>
资源描述

《数据表设计的中对主键、索引的思考》由会员分享,可在线阅读,更多相关《数据表设计的中对主键、索引的思考(7页珍藏版)》请在金锄头文库上搜索。

1、数据表设计的中对主键、索引的思考一、 数据库表设计的基本规范1.1 字段命名采用camelCase (驼峰命名法),字段采用英文,尽量不使用拼音或缩写比如: shopName,不规范的库表命名:规范的库表命名:1.2 字段的长度都是 8 的倍数门店编码 varchar(8), 产品编码 varchar(16),产品名称 varchar(64)1.3 每个表都需要一个主键,尽量避免复合主键。如果需要进行唯一限制,可设置唯一索引。比如员工信息, 设置主键为 门店号 + 员工号 , 而在实际业务中,员工可能调到其他门店,这样就需要对其门店号进行修改,对主键进行修改肯定是不合适的,主键是唯一的标识,一

2、般是不能修改的。 再比如 销售信息中,设置主键 为 门店号 + POS编号 + 单号,多个varchar型字段必然会造成读取和写入的速度的减慢,万一业务规格发生变化影响太大。而且主键一般都是聚集索引,对复合主键中任一修改都会造成记录的物理移动。1.4 如果字段只有两种选择,比如是否启用,建议采用 bit 类型ORM1.5 字段中尽量不使用text类型1.6 不建议将字段设置为可空,尽量采用默认值来代替。二、 主键和索引的关系主键是表中的一个或多个字段,它的值用于惟一地标识表中的某一条记录.,使用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列的值进行排序的一种结构,只有当经常查

3、询索引列中的数据时,才需要在表上创建索引。索引占用磁盘空间,并且降低添加、删除和更新行的速度。当然索引也有好处就是查询速度快,它利还是大于弊的所以请慎重使用索引。比如:一个学生表(ep_student )有1000条数据,给它id列建个主键和索引, 你想查询id=1000;的这条信息,如果没有索引,它就一条一条的比对查找,系统运行1000次才找到,要是创建了索引,你查询id=1000的这条信息,系统只运行一次就找到了。三、 关于主键设计一些探讨我们现在在思考一下,应该采用什么来作表的主键比较合理,申明一下,主键的设计没有一个定论,各人有各人的方法,哪怕同一个,在不同的项目中,也会采用不同的主键

4、设计原则。第一:编号作主键 此方法就是采用实际业务中的唯一字段的“编号”作为主键设计,这在小型的项目中是推荐这样做的,因为这可以使项目比较简单化,但在使用中却可能带来一些麻烦,比如要进行“编号修改”时,可能要涉及到很多相关联的其他表,就象黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”,我们再那么先知,都无法知道业务将会修改成什么?第二:自动编号主键 这种方法也是很多朋友在使用的,就是新建一个ID字段,自动增长,非常方便也满足主键的原则,优点是:数据库自动编号,速度快,而且是增量增长,聚集型主键按顺序存放,对于检索非常有利;数字型的,占用空间小,易排序,在程序中传递也方便;

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

6、:Max加一 由于自动编号存在那些问题,所以有些朋友就采用自己生成,同样是数字型的,只是把自动增长去掉了,采用在Insert时,读取Max值后加一,这种方法可以避免自动编号的问题,但也存在一个效率问题,如果记录非常大的话,那么Max()也会影响效率的;更严重的是并发性问题,如果同时有两人读到相同的Max后,加一后插入的ID值会重复,这已经是有经验教训的了。第四:自制加一 考虑Max加一的效率后,有人采用自制加一,也就是建一个特别的表,字段为:表名,当前序列值。这样在往表中插入值时,先从此表中找到相应表的最大值后加一,进行插入,有人可能发现,也可能会存在并发处理,这个并发处理,我们可以采用loc

7、k线程的方式来避免,在生成此值的时,先Lock,取到值以后,再unLock出来,这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题:在与其他系统集成时,脱离了系统中的生成方法后,很麻烦保证自制表中的最大值与导入后的保持一致,而且数字型都存在上面讲到的“o”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的,应该字符型主键可以应付很多我们意想不到的情况。第五:GUID主键 目前一个比较好的主键是采用GUID,当然我是推荐主键还是字符型的,但值由GUID生成,GUID是可以自动生成,也可以程序生成,而且键值不可能重复,可以解决系统集

8、成问题,几个系统的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 键,可能会带来两方面的消极影响:存储空间增大;索引时间较慢。 四、 一个主键和索引的 例子主表 从表

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 建筑/环境 > 综合/其它

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号