即使是一个非常简单的数据库应用系统,它的数据量增加到一定程度也会引起发一系列问题。如果在设计数据库的时候,就提前考虑这些问题,可以避免由于系统反映迟缓而引起的用户抱怨。
技巧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点看你的需求,我个人是不建议的。
网站数据库,是选SQLServer还是Aess好,可能您会说:选MySQL好,不过现在只是讨论IISASP这种架构下的选择,不讨论ApachePHP的情况
如果您现在是在局域网中使用,而且软件的价格成本不是考虑的因素,那当然是用SQLServer好了,似乎这个问题没什么好讨论的
不过在互联网上就不太一样了,因为大部分做网站的人都是租用别人的虚拟主机,比较常见的组合是PHPMySQL或ASPACCESS或ASPSQLServer,下面就使用ACCESS及SQLServer做一个比较:成本使用SQLServer的虚拟主机报价一般是使用ACCESS的15至25倍
性能就数据库的处理能力和稳定性ACCESS和SQLServer当然是没得比的,但是有一点必须注意的是,在互联网上使用SQLServer和在局域中使用是大不一样的,如果你现在已经在用,请打开“SQL查询分析器”,连接上SQLServer服务器,执行“EXECsp_who”,你可能看到返回的行数有几百行,也就是说你所在SQLServer服务器正在处理几百个连接,然后再执行“selectcount()frommaster”,你可以看这个数字也是在几百以上,也就是说你所在SQLServer服务器上有好几百个数据库
相比之下,你使用的ACCESS文件只有你一个站点在使用,通过这些参数对比,就不能简单地认为使用SQLServer会比使用ACCESS获得更好的性能了
开发在开发能力方面ACCESS和SQLServer当然不在一个档次上,ACCESS没有表的外键和存储过程,可使用的SQL函数也远不如SQLServer,而且ACCESS的界面设计能力在做网站数据库时是用不上的,而且ACCESS没有提供象“SQL查询分析器”这样的自由SQL语句编写调试工具
维护在互联网上对数据库进行维护,SQLServer可以通过“企业管理器”(效果不好,经常连不上去)或“查询分析器”进行管理及维护,前提是SQLServer服务器开放了TCP/IP连接及你能直接连接到互联网或你的代理服务器开通了1433端口
而ACCESS一但把文件上传到网站之后,如果没有辅助工具或自已编写ASP脚本,是无法进行在线维护 *** 作的,唯一的方法是通过FTP把文件拿到本地进行离线 *** 作
从以上的比较可以看出,使69用ACCESS数据库在成本上是有优势,性能上也未必见差,但开发及上线后的维护能力不足,不过使用“网际数据库浏览器”可以弥补这方面的不足,这个软件可以在把ACCESS文件上传到网站后仍能在线地对ACCESS数据库进行查询、插入、更新及删除等 *** 作,这一点是其他基于ODBC连接的数据库开发辅助工具所没有的
方法:
要说数据库,一般以SQLServer作为入门的学科,它适合中小型项目开发,而现在比较流行于大型开发的有:
Oracle
现在具有企业大型软件的绝对占有率
DB2在以IBM服务的公司以及单位(中国银行)
MySql相对不是很正式的开发,使用MySql
当然还有一些:Aess(桌面数据库),FoxPro(中国教育),Informix的数据库系统
刚开始入门的时候可以找点视频教程来学习,视频教程一般讲得比较好,但不要企图于通过它达到比较高的水平。然后要学会将自己所知道的去实践,多实践。当觉得实践到一定程度而没有什么冲劲了,就去学习理论,当觉得理论知识需要发挥的时候就去实践,时间的周期不一定,没有什么定论,但自己的时间安排需要定论就可以了。
一直都认为在计算机行业要学会一门技术太简单了,但如果要把技术发挥到一定程度就有难处了,一定程度是什么意思,就是把技术如何发挥到具体的业务之中,会动脑筋去思考,而把技术作为相对次要的东西了。
数据库的DBA人员需要兼有系统分析员和运筹学的业务素质。在技术上讲,数据库的前续学科是“数据结构”。
1数据库是非常快的数据处理程序,其内在的本质依旧是"文件"因为Windows *** 作系统管理机制就有:磁盘、文件、目录。Linux的方式只有文件。所以数据库重本质的角度来说是一种平台软件,是将文件翻译成逻辑语言的软件,成为软件程序数据交换的中心,为什么那,一个很重要的原因就是“快”,还有就是“安全”、“集成”等等。因为以前的语言程序要处理数据要编写大量算法十分麻烦而且很容易出错等等。大家就想到集成了。
2其实,要谈到 *** 作数据库,简单的就太简单了,但是数据库最难的不是 *** 作,而是在数据库的设计上。一个大型程序设计者肯定是一个数据库的高手,因为大型程序要死板地去完成它是非常困难和不理智也是不安全不稳定的,要充分利用自己所有的能力去挖掘其数据之间的奥秘,然后体系化数据库结构,相当于在数据库中如何层次化地建立数据结构。将需求中的矛盾事物改变成可以相互融合的。
数据库 *** 作简单是指一般 *** 作,如果难的 *** 作还是有点技术的,但还是难不到那里去。
3为什么说上面的东西都很简单那,因为只要会,那就可以了,而设计方面的东西是永远不是那么简单的,永远带有创新和追求,没有最高的境界。
就一个十分常见的问题,如何在数据库中配合好人员、角色、权限、类别、级别、可 *** 作性这几者的关系,如果是没有经验的人直接上手可能会乱来(最早也是这样的)。有经验的人也会设计一段时间,而且随着软件复杂性的增加,其数据库的这几者之间的复杂性就越来越复杂。所以大型软件是非常难的。就一个很简单的例子,在很多的网站中,有上百的栏目信息,而每一个栏目间又保持独立。的位置和的信息都是动态更新的。某些网站的可 *** 作性都以树型结构提供,而树型结构的子树类别和和叶子都是不重复而不错误。而且其层数都是动态的。有些人可以通过前台的判定语句来执行树型结构的生成,但总之,数据库是一门入门容易却达到高手很难的学科,通过不断在失败中吸取经验,才能得到一些书籍上无法学会的东西,那才是真正的高手。也就是说,学技术是很快的,要会将技术运用于实际的业务分析,才可以成为一个自我型的DBA,而不是一个简单的程序员。
方法/步骤
常见数据库设计
一主多从
冗余读库带来的副作用:读写有延时,可能不一致;写仍然是单点,不能保证写高可用。
主库冗余
存在数据不一致问题
数据读取速度
利用缓存来实现
常见缓存设计如下
以上就是关于大数据量的数据库表设计技巧全部的内容,包括:大数据量的数据库表设计技巧、设计网页常用的数据库、我想学习数据库,该怎么办(数据库自学)等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)