Oracle数据库的几种设计规范-北京锐智互动软件开发

    一般情况下，可以从两个方面来判断数据库是否设计的比较规范，1是看是否拥有大量的窄表，2是宽表的数量是否足够的少，如果符合这两个条件，则可以说明这个数据库的设计水平还是比较高的，当然这是两个表面上的指标，为了达到数据库设计规范的要求，一般来说，需要符合以下几个要求。

    1.  表中要避免可为空的列：
    虽然表中允许有空列，但是，空字段是一种比较特殊的数据类型，数据库在处理的时候 需要进行特殊的处理，这样的话，就会增加数据库处理记录的复杂性，当表中要比较多的空字段时，在同等条件下，数据库处理的性能会降低许多，所以，虽然在数据库表的设计的时候，允许表中具有空字段，但是，我们应该尽量避免，若的确需要的话，可以通过一些折中的方式，来处理这些空字段，让他对数据库性的影响降到最低。
    通过设置默认值的形式，来避免空字段的产生，如一个商城VIP系统，有的时候身份证号字段可以为空，因为不是每个人都能记得住身份证号的，办理业务时身份证没带身上不能及时提供，因此身份证号码字段可以为空，满足这些特殊需求，但是，在数据库设计的时候，就要做一些处理了，如果用户没有输入的时候，把这个字段的val默认值改为0/1，这样能避免空字段的产生。若是一张表中，允许为空的列比较多，接近全部列数的三分之一，而且，这些列在大部分情况下，都是可有可无的，如果数据库管理员遇到这样的状况，建议另外建立一张副表，以保存这些列，然后通过关键字把主表和副表关联起来，把数据存储在两个独立的表中是的主表的设计更为简单，同时也能够满足存储空值的信息需要。
    2. 表不应该要有重复的Key或val：
    如果现在有一个进销存系统，这个系统中有一张成品基本信息表。这个产品开发有时间可以是一个人完成。
    如进销存管理中，还需要对客户的联系人进行管理，有时候，企业可能只知道客户一个采购员的姓名，但是必要情况下，企业需要对客户的采购人员，仓库人员，财务人员共同进行管理，因为在订单上，可能需要填入采购代表的名字，在出货单上，则需要填入仓库管理人员的名字等等。
    为解决这个问题，有多个实现方式，但是，如果设计不会理的话，就会导致重复的val和key，如我们也可以这么设计。吧客户信息，联系人都放入同一张表中，为了解决多个联系人问题，可以设置第一个联系人 第一联系人电话 ，第二联系人 第二联系人电话等等，如果更多就会有更多字段加入。
    可是如果这么设计会有一系列问题，如客户的采购员流动性比较大，一年有七八个采购员，这样的话在用到这样的设计就显然不合理了。所以，在数据库设计的时候要尽量避免这种重复的key或者val的产生，如果用到这种情况，就需要改变一下策略，如：吧客户联系人另外设置一张表，然后通过客户ID把供应商信息表跟客户联系人信息连接起来，就是说尽量把重复的key放至到一张独立的表中进行管理，然后通过视图或者其他手段把这些独立的表关联起来
    3. 表中记录应该有一个标识符：
    在数据库表设计的时候，数据库管理员就应有个好习惯，用一个ID号码 标识进行记录，而不是通过名字 编号等字段对记录进行区分，每个表都应该有一个id任何两个记录都不能共用一个id值 另外 这个id值最好有数据库来进行自动管理，而不要吧这个任务给前台应用程序，否则 很容易产生id值不统一的情况
    4. 数据库对象要有统一的前缀名：
    一个比较复杂的应用系统，其对应的数据表往往数以千计，钥匙让数据库管理员看到对象名就了解这个数据库对象所起的作用 这样比较困难，而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到数据对象对发愁。为此在开发数据库之前，最好花时间去制定一个数据库的对象的前缀命名规范，
    如在设计数据库时和前台应用程序协商，确定合理的命名规范，如和物料管理模块相关的表可以用M为前缀，而订单管理相关的就用C作为前缀，具体采用什么前缀就根据用户的爱好，但是注意 这个命名规范应该在数据库管理员和前台应用程序开发者之间达成共识，并且严格暗战这个命名规范来定义对象名。
    其次 表 视图 函数等较好也要有统一的前缀，如视图可以用V为前缀 函数用F为前缀 这样数据库管理员无论在日常管理还是对象引用都能在最短的时间找到自己需要的对象。
    5. 尽量只存储单一实体类型数据：
    这里实体类型和数据类型不是一回事，要注意区分，这里讲的实体类型是指所需要描述对象的本身 举个例子 如现在有一个图书馆系统，有图书基本信息，作者信息两个实体对象，若用户要吧这两个实体对象信息放在同一张表中也可以，如果把表设计成图书的名字，作者等等如果这样设计的话，回给后续的维护带来麻烦
    如果后续有书出版时，就需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度，而且作者的情况有变，如住址修改，这样还会修改每本书的记录，同属若这个作者的数从库中全部删除后，跟着这个作者的信息也就没了很明显这不符合数据库设计规范要求。
    遇到这种情况 建议把上面的这张表分为三个独立的表，分别为图书基本表 ，作者表 图书合作者对应表等等 这样设计 在遇到问题也能迎刃而解。
  北京锐智互动软件开发具有多类产品的研发和设计经验，产品种类包括：电子商务、生活服务、金融服务、新媒体、教育教学、手机游戏等多领域的app应用及组件，锐智互动以专业的解决方案，快速的需求反应，灵活的开发流程和细致的客户服务，为企业提供全方位的移动应用开发，推广运营服务。近年来近百家国内外各行各业的客户，致力于想客户所想的原则，努力为客户提供更进准更完善的移动互联网应用及解决方案。