业务的拉扯以及主导设计，告知开发怎么去做。，和业务的拉扯以及主导设计，告知开发怎么去做。

首先 需要说的就是系统的错误跟踪问题，开发人员设计数据字典的时候，往往考虑到的业务应该怎样怎样，但是不会考虑到业务如果错了会怎样怎样，如果出错该如何简单定位错误数据，如何简单找出错误日志；其次，是这个数据库的架构在设计中需要考量的因素。 在7*24小时的系统中，数据字典的设计本身是需要考虑到高可用，复制，移植，

2  关于表的主键设计

  原则： 每个表，都应该有一个主键，并且是一个number类型的主键。 
  描述： 表上有pk，那么每条数据的更新都是可以按照主键跟新，对表的并发是非常有好处的。在oracle数据库中，pk和索引还是有一些区别的，主要就是null数据的问题，由于null不进入索引，所以索引不能限制null的重复性，但是pk是可以限制的。
曾经有开发问我，主键是否可以是一个非number字段的值，当然理论上是没有问题。一般这类的pk生成都是有算法的，比如：时间+某种规则。但是我不建议这样的使用，主要的问题就是有2个
    （1）性能问题，在Oracle和M

ysql数据库中，数值的运算绝对不会比字符的运算慢。
    （2） 数据库架构：如果在多主数据库环境中，为了避免表的主键冲突，都需要把主键错开。按照某个规则生成的字符串依然需要套用这个规则。既然一定要分开，数值会比字符串更加方便。 
        举例来说：在一个双主的数据库环境中，可以考虑A机器的所有表的主键都是按照1结尾，步长=10，而B机器的所有表的主键都是按照2结尾，步长=10

在我看来，所有的表均需要有添加时间和最后修改时间的设计，特殊的，如果这个表是一张流水表，那么可以只需要有最后修改时间，因为此时最后修改时间=添加时间。

   (2) 有一天，数据库要移植了，由于需要7*24小时在线，所以数据是需要在提供对外业务的时候移植。DBA要求开发写一个增量程序，把移植时间内的变量数据移植成功后再覆盖一遍……然后，必须等待数据库所有的表均有最后修改时间才可以，否则这个增量程序就无法上线，无法上线就无法移植，然后……

运维的角度给出了一些数据库设计经验。所有的开发，均希望可以设计出有扩展性的系统，那么系统如何能够有扩展性，不同的角度是非常重要的，只有通过多个角度去看待问题，才可以设计出好的数据字典。

3.

数据是否需要全量同步，增量同步是否可以满足需求，不同步可以不？

四、日志表转储机制

保留多长时间的数据，是否某些日志不需要保留那么长的时间

为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的 联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
表内的每一行都应该的标识（有键）。
表内不应该存储依赖于其他键的非键信息。

最后：

6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

画数据流图，生成应用程序。

1. http://blog.itpub.net/24686519/viewspace-733658/

2. http://blog.itpub.net/7416120/viewspace-967569/

3. http://blog.itpub.net/617982/viewspace-1411940/