本文目录一览

1,数据库开发需注意哪些问题

在数据库设计之前首先应该有明确的数据库设计规范,包括表,视图,字段等的命名规范,设计约束和存储过程等的编码规范。同时数据库设计应该遵守从逻辑设计到物理设计的实现思路,在充分了解客户需求的情况下,创建数据字典和ER模型,遵守数据库的设计范式等基本要求进行设计。
1 数据库理念必须理解2 sql语句必须熟练3 存储过程 事件 等必须会用4 流行的数据库必须会用 大型orcale db2 小型的sql server mysql5 注意备份机制,呵呵不要轻易的delete 和updata

数据库开发需注意哪些问题

2,创建数据库时应注意什么问题

1.在创建数据库时应该注意哪些问题?数据库在创建的时候可以设置他的扩展大小,但是数据库的大小不是固定的 它的数据实时地不断的增大.注意不要到MASTER数据库中创建用用户对象.2.怎样确定数据库的大小?创建数据库时可以创建其大小3.比较用不同方法创建数据库时,确定数据文件和日志文件的方法。4.可以在MASTER数据库中创建用户对象吗?为什么?不要在MASTER数据库中创建任何用户对象,因为MASTER数据库包含系统表,这些系统表存储SQL SERVER所用的系统信息5.可以用哪些方法修改数据库?1)打开企业管理器,展开服务器组,然后展开SQL SERVER服务器.2)在”数据库”文件夹中,右击要更改的数据库(如:bbsdb),然后单击”属性”命令,打开数据库属性对话框用TRANSANCT-SQL也能修改数据库语句为:ALTER DATABASE

创建数据库时应注意什么问题

3,在设计数据库时需要注意哪些

问题有点大,提个思路吧:1 所用的数据库类型?Oracle 、Mysql、DB2 还是其它?2 面向的应用?是OLTP 还是 DSS/OLAP?3 系统的存储结构如何?指系统的文件系统类型、磁盘实现、是否支持冗余、是否支持缓存写入等,会影响到数据库的压缩、日志、统计等属性设置。4 是新项目的数据库,还是属于迁移的?即对数据的设计和修改的范围和限制。5 数据库级别的考虑?空间、日志、字符集、是否闪回、数据块大小等。6 表级别的考虑?数据类型、分区、主键、唯一键、索引、聚集索引、外键、全文查询、数据块大小、压缩、日志等。7 视图、存储过程、触发器等设计,用于保证事务、便于程序访问的相关设计;按以上具体参阅资料考虑各部分的设计和注意事项吧。
1.要注意:三大范式 你搞数据库的应该知道 我不累赘了 2,先要明白 你要实现什么功能 先想出主要的几张表 然后给慢慢细化 3.在2的基础上 已经想好 该有的表了 理清他们之间的关系 4.要从客户的角度考虑 尽量提高客户体验 上述只是个人意见 提供给你参考 -----------------------万能的分割线------------------------------------- 提示:理论看太多,还不如自己动手 在有大量代码的基础 再看理论效果会很好 还有一点,写代码的 要耐得住寂寞 耐不住,我劝你趁早别干 转行吧

在设计数据库时需要注意哪些

4,一个好的数据库要注意什么

容量,耦合度,数据库的设计
要符合数据库的3大范式 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于图3-2 中的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而言之,第一范式就是无重复的列。 2 第二范式(2NF) 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。 3 第三范式(3NF) 满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。 然后就要注意关系了例如:一对一,一对多,多对多。
三大范式必不可少~ 如果是企业级的话~ 还需要考虑数据库设计的成本与数据库维护相关问题!
基础加经验,扎实的基础和丰富的经验!
正常一个好的数据库都是跟你做的程序有关系的,数据库的表,字段,关联的能满足程序的需要,设计合理,并且在查询需要的数据的时候,尽量能相对简单的查询到客户所需要的数据, 根据客户的要求做出约束(例如那几个字段不能重复等),根据查询需要设置出合理的索引,在查询的时候提高查询速度
能较好的处理各种关系,访问速度快,给用户的感觉好!

5,一般在写SQL时需要注意哪些问题可以提高查询的效率

1.尽量使用索引,索引很多情况下可以提高查询效率2.避免使用or语句3.避免使用not in语句4.可以使用exists和not exists代替in和not in语句……还有很多种情况 你网上可以很容易查到
1. SQL优化的原则是:将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。 调整不良SQL通常可以从以下几点切入: ? 检查不良的SQL,考虑其写法是否还有可优化内容 ? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写 ? 检查优化索引的使用 ? 考虑数据库的优化器 2. 避免出现SELECT * FROM table 语句,要明确查出的字段。 3. 在一个SQL语句中,如果一个where条件过滤的数据库记录越多,定位越准确,则该where条件越应该前移。 4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引,这样查询时只进行索引扫描,不读取数据块。 5. 在判断有无符合条件的记录时建议不要用SELECT COUNT (*)和select top 1 语句。 6. 使用内层限定原则,在拼写SQL语句时,将查询条件分解、分类,并尽量在SQL语句的最里层进行限定,以减少数据的处理量。 7. 应绝对避免在order by子句中使用表达式。 8. 如果需要从关联表读数据,关联的表一般不要超过7个。 9. 小心使用 IN 和 OR,需要注意In集合中的数据量。建议集合中的数据不超过200个。 10. <> 用 < 、 > 代替,>用>=代替,<用<=代替,这样可以有效的利用索引。 11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。 12. 对于复合索引要注意,例如在建立复合索引时列的顺序是F1,F2,F3,则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致,且必须包含第一列。只能是F1或F1,F2或F1,F2,F3。否则不会用到该索引。 13. 多表关联查询时,写法必须遵循以下原则,这样做有利于建立索引,提高查询效率。格式如下select sum(table1.je) from table1 table1, table2 table2, table3 table3 where (table1的等值条件(=)) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。 注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。 14. 子查询问题。对于能用连接方式或者视图方式实现的功能,不要用子查询。例如:select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替:select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。 15. 在WHERE 子句中,避免对列的四则运算,特别是where 条件的左边,严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。 16. 如果在语句中有not in(in)操作,应考虑用not exists(exists)来重写,最好的办法是使用外连接实现。 17. 对一个业务过程的处理,应该使事物的开始与结束之间的时间间隔越短越好,原则上做到数据库的读操作在前面完成,数据库写操作在后面完成,避免交叉。 18. 请小心不要对过多的列使用列函数和order by,group by等,谨慎使用disti软件开发t。 19. 用union all 代替 union,数据库执行union操作,首先先分别执行union两端的查询,将其放在临时表中,然后在对其进行排序,过滤重复的记录。 当已知的业务逻辑决定query A和query B中不会有重复记录时,应该用union all代替union,以提高查询效率。

文章TAG:数据  数据库  应该  注意  数据库应该注意哪些问题  
下一篇