数据库设计原则

1. 数据库设计原则

本系统中数据库的设计，要考虑和遵循下列数据库设计的基本原则，以建立稳定、安全、可靠的数据库。
1)一致性原则:对数据来源进行统一、系统的分析与设计，协调好各种数据源，保证数据的一致性和有效性。
2)完整性原则:数据库的完整性是指数据的正确性和相容性。要防止合法用户使用数据库时向数据库加入不合语义的数据。对输入到数据库中的数据要有审核和约束机制。
3)安全性原则:数据库的安全性是指保护数据，防止非法用户使用数据库或合法用户非法使用数据库造成数据泄露、更改或破坏。要有认证和授权机制。
4)可伸缩性与可扩展性原则:数据库结构的设计应充分考虑发展的需要、移植的需要，具有良好的扩展性、伸缩性和适度冗余。
5)规范化:数据库的设计应遵循规范化理论。规范化的数据库设计，可以减少数据库插入、删除、修改等操作时的异常和错误，降低数据冗余度等。

2. 大型数据库设计原则

 　　一个好的数据库产品不等于就有一个好的应用系统 如果不能设计一个合理的数据库模型 不仅会增加客户端和服务器段程序的编程和维护的难度 而且将会影响系统实际运行的性能 一般来讲 在一个MIS系统分析 设计 测试和试运行阶段 因为数据量较小 设计人员和测试人员往往只注意到功能的实现 而很难注意到性能的薄弱之处 等到系统投入实际运行一段时间后 才发现系统的性能在降低 这时再来考虑提高系统性能则要花费更多的人力物力 而整个系统也不可避免的形成了一个打补丁工程 笔者依据多年来设计和使用数据库的经验 提出以下一些设计准则 供同仁们参考 
  　　 命名的规范 
  　　不同的数据库产品对对象的命名有不同的要求 因此 数据库中的各种对象的命名 后台程序的代码编写应采用大小写敏感的形式 各种对象命名长度不要超过 个字符 这样便于应用系统适应不同的数据库 
  　　 游标（Cursor）的慎用 
  　　游标提供了对特定集合中逐行扫描的手段 一般使用游标逐行遍历数据 根据取出的数据不同条件进行不同的操作 尤其对多表和大表定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等特甚至死机 笔者在某市《住房公积金管理系统》进行日终帐户滚积数计息处理时 对一个 万个帐户的游标处理导致程序进入了一个无限期的等特（后经测算需 个小时才能完成）(硬件环境 Alpha/ Mram Sco Unix Sybase ) 后根据不同的条件改成用不同的UPDATE语句得以在二十分钟之内完成 示例如下 
   
  　　Declare Mycursor cursor for select  count_no from COUNT
  　　Open Mycursor
  　　Fetch Mycursor into @vcount_no
  　　While (@@sqlstatus= )
  　　Begin
  　　If  @vcount_no=   条件 
  　　操作 
  　　If  @vcount_no=   条件 
  　　操作 
  　　 
  　　Fetch Mycursor into @vcount_no
  　　End
  　　 
  　　 
  　　改为
  　　Update COUNT set  操作 for 条件 
  　　Update COUNT set  操作 for 条件 
  　　 
  　　 
  　　在有些场合 有时也非得使用游标 此时也可考虑将符合条件的数据行转入临时表中 再对临时表定义游标进行操作 可时性能得到明显提高 笔者在某地市〈电信收费系统〉数据库后台程序设计中 对一个表（ 万行中符合条件的 多行数据）进行游标操作(硬件环境 PC服务器 PII Mram NT Ms Sqlserver ) 示例如下 
  　　Create #tmp   /* 定义临时表 */
  　　(字段 
  　　字段 
  　　 
  　　)
  　　Insert into #tmp select * from TOTAL where
  　　条件  /* TOTAL中 万行 符合条件只有几十行 */
  　　Declare Mycursor cursor for select * from #tmp
  　　/*对临时表定义游标*/
  　　 
  　　 索引(Index)的使用原则 
  　　创建索引一般有以下两个目的 维护被索引列的唯一性和提供快速访问表中数据的策略 大型数据库有两种索引即簇索引和非簇索引 一个没有簇索引的表是按堆结构存储数据 所有的数据均添加在表的尾部 而建立了簇索引的表 其数据在物理上会按照簇索引键的顺序存储 一个表只允许有一个簇索引 因此 根据B树结构 可以理解添加任何一种索引均能提高按索引列查询的速度 但会降低插入 更新 删除操作的性能 尤其是当填充因子（Fill Factor）较大时 所以对索引较多的表进行频繁的插入 更新 删除操作 建表和索引时因设置较小的填充因子 以便在各数据页中留下较多的自由空间 减少页分割及重新组织的工作 
  　　 数据的一致性和完整性 
  　　为了保证数据库的一致性和完整性 设计人员往往会设计过多的表间关联（Relation） 尽可能的降低数据的冗余 表间关联是一种强制性措施 建立后 对父表（Parent Table）和子表(Child Table)的插入 更新 删除操作均要占用系统的开销 另外 最好不要用Identify 属性字段作为主键与子表关联 如果数据冗余低 数据的完整性容易得到保证 但增加了表间连接查询的操作 为了提高系统的响应时间 合理的数据冗余也是必要的 使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段 但是 不必要的规则和约束也会占用系统的不必要开销 需要注意的是 约束对数据的有效性验证要比规则快 所有这些 设计人员在设计阶段应根据系统操作的类型 频度加以均衡考虑 
  　　 事务的陷阱 
  　　事务是在一次性完成的一组操作 虽然这些操作是单个的操作 SQL Server能够保证这组操作要么全部都完成 要么一点都不做 正是大型数据库的这一特性 使得数据的完整性得到了极大的保证 
  　　 众所周知 SQL Server为每个独立的SQL语句都提供了隐含的事务控制 使得每个DML的数据操作得以完整提交或回滚 但是SQL Server还提供了显式事务控制语句
  　　BEGIN TRANSACTION 开始一个事务
  　　MIT TRANSACTION 提交一个事务
  　　ROLLBACK TRANSACTION 回滚一个事务
  　　事务可以嵌套 可以通过全局变量@@trancount检索到连接的事务处理嵌套层次 需要加以特别注意并且极容易使编程人员犯错误的是 每个显示或隐含的事物开始都使得该变量加 每个事务的提交使该变量减 每个事务的回滚都会使得该变量置 而只有当该变量为 时的事务提交（最后一个提交语句时） 这时才把物理数据写入磁盘 
  　　 数据库性能调整 
  　　在计算机硬件配置和网络设计确定的情况下 影响到应用系统性能的因素不外乎为数据库性能和客户端程序设计 而大多数数据库设计员采用两步法进行数据库设计 首先进行逻辑设计 而后进行物理设计 数据库逻辑设计去除了所有冗余数据 提高了数据吞吐速度 保证了数据的完整性 清楚地表达数据元素之间的关系 而对于多表之间的关联查询（尤其是大数据表）时 其性能将会降低 同时也提高了客 户端程序的编程难度 因此 物理设计需折衷考虑 根据业务规则 确定对关联表的数据量大小 数据项的访问频度 对此类数据表频繁的关联查询应适当提高数据冗余设计 
  　　 数据类型的选择 
  　　数据类型的合理选择对于数据库的性能和操作具有很大的影响 有关这方面的书籍也有不少的阐述 这里主要介绍几点经验 
  　　Identify字段不要作为表的主键与其它表关联 这将会影响到该表的数据迁移 
  　　Text 和Image字段属指针型数据 主要用来存放二进制大型对象（BLOB） 这类数据的操作相比其它数据类型较慢 因此要避开使用 
  　　日期型字段的优点是有众多的日期函数支持 因此 在日期的大小比较 加减操作上非常简单 但是 在按照日期作为条件的查询操作也要用函数 相比其它数据类型速度上就慢许多 因为用函数作为查询的条件时 服务器无法用先进的性能策略来优化查询而只能进行表扫描遍历每行 
  　　例如 要从DATA_TAB 中（其中有一个名为DATE的日期字段）查询 年的所有记录 
  lishixinzhi/Article/program/Oracle/201311/17929 
   

3. 数据库完整性的设计原则

在实施数据库完整性设计的时候，有一些基本的原则需要把握：1．根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。2．实体完整性约束、参照完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。3．另一方面，触发器的多级触发不好控制，容易发生错误，非用不可时，最好使用Before型语句级触发器。4．在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词、缩写词、表名、列名及下划线等组合，使其易于识别和记忆，如：CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。如果使用CASE工具，一般有缺省的规则，可在此基础上修改使用。5．要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。6．要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。数据库设计人员不仅负责基于DBMS的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。7．应采用合适的CASE工具来降低数据库设计各阶段的工作量。好的CASE工具能够支持整个数据库的生命周期，这将使数据库设计人员的工作效率得到很大提高，同时也容易与用户沟通。

4. 大型数据库的设计原则与开发技巧

 　　随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧 
  　　 一 成立数据小组 
  　　大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成 
  　　数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整 
  　　 二 设计原则 
   
  　　 规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询 
  　　 控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计 
  　　 库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复 
  　　 并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询 
  　　 必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息 
  　　 数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求 
  　　 头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改 
  　 　三 设计技巧 
  　　 分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率 
  　　 索引设计 对于大的数据库表 合理的索引能够提高整个数据库的操作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的操作效率 
  　　 数据操作的优化 在大型数据库中 如何提高数据操作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔操作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统操作的核心 有可能在操作时被其他进程锁定 因而使整个事务操作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O操作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O操作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表操作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop操作再进行重建 
  　　 数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整 
  　　 必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率 
  　　 避免长事务 对单个大表的删除或插入操作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序操作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列操作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务 
  　　 适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能 
  lishixinzhi/Article/program/SQL/201311/16498 
   

5. 设计数据库系统所遵循的一系列原则是什么?

数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！
　那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：
　　1、数据库设计最起码要占用整个项目开发的40%以上的时间
　　数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。
　　2、数据库设计不仅仅停留于页面demo的表面
　　页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
　　3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了
　　每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。
　　4、数据库设计时就要考虑到效率和优化问题
　　一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。
　　5、添加必要的（冗余）字段
　　像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。
　　6、设计合理的表关联
　　若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。
　　7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联
　　这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
　　8、选择合适的主键生成策略

6. (20) 数据库设计包括两个方面的设计内容，它们是______。

A.概念设计和逻辑设计
分析：
数据库设计的设计内容包括：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护。
概念设计
对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中诸处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。
以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。
第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。
逻辑设计
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

扩展资料：
数据结构设计形成过程：
需求分析阶段：综合各个用户的应用需求。
概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式。
逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式。
物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。

参考资料来源：数据库设计-百度百科

7. 在系统设计中，对数据库的设计应考虑哪些设计原则

　数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！
　那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：
　　1、数据库设计最起码要占用整个项目开发的40%以上的时间
　　数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。
　　2、数据库设计不仅仅停留于页面demo的表面
　　页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
　　3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了
　　每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。
　　4、数据库设计时就要考虑到效率和优化问题
　　一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。
　　5、添加必要的（冗余）字段
　　像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。
　　6、设计合理的表关联
　　若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。
　　7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联
　　这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
　　8、选择合适的主键生成策略

8. 在系统设计中，对数据库的设计应考虑哪些设计原则？

　数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！
　那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：
　　1、数据库设计最起码要占用整个项目开发的40%以上的时间
　　数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。
　　2、数据库设计不仅仅停留于页面demo的表面
　　页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
　　3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了
　　每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。
　　4、数据库设计时就要考虑到效率和优化问题
　　一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。
　　5、添加必要的（冗余）字段
　　像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。
　　6、设计合理的表关联
　　若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。
　　7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联
　　这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
　　8、选择合适的主键生成策略