数据库设计注重在哪个地方,数据库开发需注意哪些问题
来源:整理 编辑:黑码技术 2024-05-06 09:11:56
本文目录一览
1,数据库开发需注意哪些问题
在数据库设计之前首先应该有明确的数据库设计规范,包括表,视图,字段等的命名规范,设计约束和存储过程等的编码规范。同时数据库设计应该遵守从逻辑设计到物理设计的实现思路,在充分了解客户需求的情况下,创建数据字典和ER模型,遵守数据库的设计范式等基本要求进行设计。1 数据库理念必须理解2 sql语句必须熟练3 存储过程 事件 等必须会用4 流行的数据库必须会用 大型orcale db2 小型的sql server mysql5 注意备份机制,呵呵不要轻易的delete 和updata
2,在设计数据库时需要注意哪些
问题有点大,提个思路吧:1 所用的数据库类型?Oracle 、Mysql、DB2 还是其它?2 面向的应用?是OLTP 还是 DSS/OLAP?3 系统的存储结构如何?指系统的文件系统类型、磁盘实现、是否支持冗余、是否支持缓存写入等,会影响到数据库的压缩、日志、统计等属性设置。4 是新项目的数据库,还是属于迁移的?即对数据的设计和修改的范围和限制。5 数据库级别的考虑?空间、日志、字符集、是否闪回、数据块大小等。6 表级别的考虑?数据类型、分区、主键、唯一键、索引、聚集索引、外键、全文查询、数据块大小、压缩、日志等。7 视图、存储过程、触发器等设计,用于保证事务、便于程序访问的相关设计;按以上具体参阅资料考虑各部分的设计和注意事项吧。1.要注意:三大范式 你搞数据库的应该知道 我不累赘了 2,先要明白 你要实现什么功能 先想出主要的几张表 然后给慢慢细化 3.在2的基础上 已经想好 该有的表了 理清他们之间的关系 4.要从客户的角度考虑 尽量提高客户体验 上述只是个人意见 提供给你参考 -----------------------万能的分割线------------------------------------- 提示:理论看太多,还不如自己动手 在有大量代码的基础 再看理论效果会很好 还有一点,写代码的 要耐得住寂寞 耐不住,我劝你趁早别干 转行吧 
3,设计大型数据库需要注意哪些地方
?VARCHAR和CHAR类型,varchar是变长的,需要额外的1-2个字节存储,能节约空间,可能会对性能有帮助。但由于是变长,可能发生碎片,如更新数据;?使用ENUM代替字符串类型,数据实际存储为整型。?字符串类型?要尽可能地避免使用字符串来做标识符,因为它们占用了很多空间并且通常比整数类型要慢。特别注意不要在MYISAM表上使用字符串标识符。MYISAM默认情况下为字符串使用了压缩索引(Packed Index),这使查找更为缓慢。据测试,使用了压缩索引的MYISAM表性能要慢6倍。?还要特别注意完全随机的字符串,例如由MD5()、SHA1()、UUID()产生的。它们产生的每一个新值都会被任意地保存在很大的空间范围内,这会减慢INSERT及一些SELECT查询。1)它们会减慢INSERT查询,因为插入的值会被随机地放入索引中。这会导致分页、随机磁盘访问及聚集存储引擎上的聚集索引碎片。2)它们会减慢SELECT查询,因为逻辑上相邻的行会分布在磁盘和内存中的各个地方。3)随机值导致缓存对所有类型的查询性能都很差,因为它们会使缓存赖以工作的访问局部性失效。如果整个数据集都变得同样“热”的时候,那么把特定部分的数据缓存到内存中就没有任何的优势了。并且如果工作集不能被装入内存中,缓存就会进行很多刷写的工作,并且会导致很多缓存未命中。?如果保存UUID值,就应该移除其中的短横线,更好的办法是使用UHEX()把UUID值转化为16字节的数字,并把它保存在BINARY(16)列中。
4,数据库分析设计关键点是什么
个人原创见解:首先你需要清楚了解需求,以及勾勒出系统的大致的功能,然后确认整个需求中的实体,及实体属性<即字段>,最后是关系<满足三大范式>.
其中我觉得:了解需求,是为设计出足够系统使用的数据,<即是够用>
处理好关系是为了:方便编程者的使用,和系统的时效性.<即是好用>
这不难看出,确认实体是最要的,因为了解需求,处理关系都是辅助确认实体而已.
但若要设计出一个好的数据库,则方方面面都需要注意,都很关键.
个人见解,才疏学浅,仅供交流参考.呵呵!数据库的设计一般需要分成若干个步骤,根据系统的复杂性,这些步骤也会相应增多。但是其中也有一些主要的步骤必须遵守!
1:确定哪些是表,哪些是键
对于数据库而言,表可以理解为一类型的数据的集合,表中的任何一行数据都可以还原成一个原型。所以在确定一个数据库表的时候你首先需要确定有多少个“原型”,而键就应该是这种原型的特点或者特性。他们可以是唯一的也可以是不唯一的。
2:实用,避免空想
设计数据库时要注意不要试图设计一个“不需要更改”或者“以后几乎不需要更改”的数据表,那是浪费经历和数据库资源的。因此所设计的表应该尽量是短小的,独立的。
3:共享
数据库的共享策略是数据库设计能力的一个重要痕量指标。一些初级的设计人员往往认为一个键值如果可以服务多个数据那么可以提高数据的共享能力。这样的理解是错误的,不可否认这的确可以极大程度的提高数据库的共享能力,但是同时增加了数据之间的“耦合”。“耦合”对于软件设计人员来说是致命的。耦合带来的弊端非常之多,问问篇幅限制我就不多说了。下面介绍几种我个人积累的方案。1>通过映射表来实现共享 2>通过码或者(数列)来提高共享 3>通过无意义的函数化了的连接健 4>子母表
4:确定字段的类型
确定字段的容量对于数据库的查询和数据的大小有非常直接的关系。我以前见过人设计数据库的时候,字符串的类型长度就是500,甚至TEXT.数字就是int.所有的字段只有这2个类型。这样显然是不对的,既减少了数据对于字段的自然约束降低了数据的质量,又浪费了空间。
5:表的容量
表的容量对于设计者而言是必须一开始就考虑到的,一张表的大概数据量和更改频率是设计这张表之前就要实现全面考虑的。比如一个大数据量的表就应该尽量避免外键或者NvN的链接出现。如果实在要出现,那么对这张表的就应该事先考虑好切分的策略。
6:索引
不用多说了,建立索引是优化查询的必备知识。建立一个具备最多信息的表让索引的资源花费的更加值得是很明智的。
能想到的就暂时这么多了。
文章TAG:
数据 数据库 设计 注重 数据库设计注重在哪个地方