如何设计、优化 多个 多对多的数据库表

如何设计、优化 多个 多对多的数据库表,第1张

若表比较多,每一个表里面的数据比较多的话,若在查询数据 Where aColName1=bColName1 and bColName2=cColName2……等查询语句的时候,会导致速度比较慢

这样最好对这些关联字段ColNam1,ColNam2……等字段增加索引,能明显加快查询速度。

1.首先打开我们的访问程序,要打开的方法是点击开始——所有程序。

2.在所有程序中找到microsoftoffice文件夹并打开它。

3.找到access并单击open。

4.在access接口中,单击file——new。

5.在新建对话框右侧选择界面版本,选择空数据库

6.选择一个存放文件的位置,然后明确数据库,点击创建。

7.所以我们创建了一个数据库。

1数据库中的多对多关联关系一般需采用中间表的方式处理,将多对多转化为两个一对多。

2通过表的关系,来帮助我们怎样建表,建几张表。

一对一

一张表的一条记录一定只能与另外一张表的一条记录进行对应,反之亦然。

学生表:姓名,性别,年龄,身高,体重,籍贯,家庭住址,紧急联系人

其中姓名、性别、年龄、身高,体重属于常用数据,但是籍贯、住址和联系人为不常用数据

如果每次查询都是查询所有数据,不常用的数据就会影响效率,实际又不用

常用信息表:ID(P),姓名,性别,年龄,身高,体重

不常用信息表:ID(P),籍贯,家庭住址,紧急联系人

解决方案:将常用的和不常用的信息分享存储,分成两张表

不常用信息表和常用信息表,保证不常用信息表与常用信息表能够对应上:找一个具有唯一性的

字段来共同连接两张表。

一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录,反之亦然。

一对多

一张表中有一条记录可以对应另外一张表中的多条记录;但是反过来,另外一张表的一条记录

只能对应第一张表的一条记录,这种关系就是一对多或多对一

母亲与孩子的关系:母亲,孩子两个实体

母亲表:ID(P),名字,年龄,性别

孩子表:ID(P),名字,年龄,性别

以上关系:一个妈妈可以在孩子表中找到多条记录(也可能是一条),但是一个孩子只能找到一个妈妈

是一种典型的一对多的关系。

但是以上设计:解决了实体的设计表问题,但是没有解决关系问题,孩子找不到母亲,母亲也找不到孩子

解决方案:在某一张表中增加一个字段,能够找到另外一张表中的记录:在孩子表中增加一个字段

指向母亲表,因为孩子表的记录只能匹配到一条母亲表的记录。

母亲表:ID(P),名字,年龄,性别

孩子表:ID(P),名字,年龄,性别,母亲表ID(母亲表主键)

多对多

一对表中(A)的一条记录能够对应另外一张表(B)中的多条记录;同时B表中的一条记录

也能对应A表中的多条记录

老师和学生

老师表 T_ID(P),姓名,性别

学生表 S_ID(P),姓名,性别

以上设计方案:实现了实体的设计,但是没有维护实体的关系

一个老师教过多个学生,一个学生也被多个老师教过

解决方案:增加一张中间关系表

老师与学生的关系表:ID(P),T_ID,S_ID

老师表与中间表形成一对多的关系,而中间表是多表;维护了能够唯一找到一表的关系;

同样的学生表与中间表也是一个一对多的关系;

学生找老师:找出学生ID--->中间表寻找匹配记录(多条)--->老师表匹配(一条)

老师找学生:找出老师ID--->中间表寻找匹配记录(多条)--->学生表匹配(一条)

大数据量的数据库表设计技巧

即使是一个非常简单的数据库应用系统,它的数据量增加到一定程度也会引起发一系列问题。如果在设计数据库的时候,就提前考虑这些问题,可以避免由于系统反映迟缓而引起的用户抱怨。

技巧1:尽量不要使用代码。比如性别这个字段常见的做法:1代表男,0代表女。这样的做法意味着每一次查询都需要关联代码表。

技巧2:历史数据中所有字段与业务表不要有依赖关系。如保存打印发票的时候,不要只保留单位代码,而应当把单位名称也保存下来。

技巧3:使用中间表。比如职工工资,可以把每一位职工工资的合计保存在一张中间表中,当职工某一工资项目发生变化的时候,同时对中间表的数据做相应更新。

技巧4:使用统计表。需要经常使用的统计数据,生成之后可以用专门的表来保存。

技巧5:分批保存历史数据。历史数据可以分段保存,比如2003年的历史数据保存在 《2003表名》中,而2004年的历史数据则保存在《2004表名》中。

技巧6:把不常用的数据从业务表中移到历史表。比如职工档案表,当某一职工离开公司以后,应该把他的职工档案表中的信息移动到《离职职工档案表》中。

1、经常查询的和不常用的分开几个表,也就是横向切分

2、把不同类型的分成几个表,纵向切分

3、常用联接的建索引

4、服务器放几个硬盘,把数据、日志、索引分盘存放,这样可以提高IO吞吐率

5、用优化器,优化你的查询

6、考虑冗余,这样可以减少连接

7、可以考虑建立统计表,就是实时生成总计表,这样可以避免每次查询都统计一次

8、用极量数据测试一下数据

速度,影响它的因数太多了,且数据量越大越明显。

1、存储将硬盘分成NTFS格式,NTFS比FAT32快,并看你的数据文件大小,1G以上你可以采用多数据库文件,这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。

2、tempdbtempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID0上,这样它的性能最高,不要对它设置最大值让它自动增长

3、日志文件日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上,这样也可以提高硬盘I/O性能。

4、分区视图就是将你的数据水平分割在集群服务器上,它适合大规模OLTP,SQL群集上,如果你数据库不是访问特别大不建议使用。

5、簇索引你的表一定有个簇索引,在使用簇索引查询的时候,区块查询是最快的,如用between,应为他是物理连续的,你应该尽量减少对它的updaet,应为这可以使它物理不连续。

6、非簇索引非簇索引与物理顺序无关,设计它时必须有高度的可选择性,可以提高查询速度,但对表update的时候这些非簇索引会影响速度,且占用空间大,如果你愿意用空间和修改时间换取速度可以考虑。

7、索引视图如果在视图上建立索引,那视图的结果集就会被存储起来,对与特定的查询性能可以提高很多,但同样对update语句时它也会严重减低性能,一般用在数据相对稳定的数据仓库中。

8、维护索引你在将索引建好后,定期维护是很重要的,用dbccshowcontig来观察页密度、扫描密度等等,及时用dbccindexdefrag来整理表或视图的索引,在必要的时候用dbccdbreindex来重建索引可以受到良好的效果。

不论你是用几个表1、2、3点都可以提高一定的性能,5、6、8点你是必须做的,至于4、7点看你的需求,我个人是不建议的。

项目中有的表多达70多个字段。是比较吃力了。应该是设计不合理或业务抽象的粒度不够。 追问: 数据库是公司的权威设计的,提建议也没办法,是不合适。俾人感觉数据库最好不超过20个字段能推荐几个net框架吗?除了framWork 回答: 我不是搞net的,也不好推荐不了啥框架了。只能说适合最好了。有可能自己写的一个小工具更方便。主要是思想。数据库最好不超过 20字段,在企业级应用中很难做到,因为业务比较复杂。往往一张业务单据需要的业务数据就有可能已经超过20列。我们这边是JAVA做的,一般的业务单据表差不多是20~40多列吧。不排除有些个别多一点,但是在查询时,要求列表展现18列以内,提高性能的各种手段吧。慢慢体会。再多的东西也提供不了你了,只能说说自己的认识。 追问: 呵呵,搞JAVA是我最初的打算,我还是比较喜欢java的,喜欢java的框架,开发过几个项目;现在公司用NET,最大的问题就是公司数据库设计的不合理,看起来连二范式都不符合刚刚工作,也不了解到底企业数据库是怎么设计的,是不是一定符合三范式?数据库是开发的基础,感觉软件行业也太缺这方面人才了,设计的不好,只能害我们这些程序员对了,谢谢你这么详细的指导,能交个朋友吗? 回答: 企业数据库,特别是ERP不一定要符合三范式的。有些情况,有些字段是根据业务的特性故意冗余存储的。。

以上就是关于如何设计、优化 多个 多对多的数据库表全部的内容,包括:如何设计、优化 多个 多对多的数据库表、如何建立企业资料数据库、数据库怎么设计多对多的数据表等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9369611.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-27
下一篇 2023-04-27

发表评论

登录后才能评论

评论列表(0条)

保存