数据库设计之备用字段

 

备用字段，也称 预留字段 。

 

相关描述：
　　在数据表中，不仅设计了当前所需要的字段，而且还在其中留出几个字段作为备用。
　　举例说明，我设计了一个人员表（Person），其中已经添加了各种必要的字段，包括姓名（Name）、性别（Sex）、出生年月日 （birthday）等等。大功告成之后，我忽然想到，将来系统中应该还会有很多其它与人相关的内容吧，比方说毕业院校，再比方说工作单位等等，尽管现在根本不需要填写，以后可能还是会用到的吧。好，那就加入5个varchar2型的字段，分别叫做Text1、Text2……Text5，然后又想到， 应该还有一些日期型的字段需要备用，就又建立了三个date型的字段，分别起名叫做date1、date2、date3，……

 

　　可以看到，在上面举例的数据表中，存在着大量暂时无用的字段，我们可以称之为备用字段。

　　那它们的作用是什么呢？防患于未然！等到需要的时候，就不需要在表中增加新的字段了。而且这样做的话，一个表的数据应该会被存储在相邻的物理空间中，这对于性能也是有好处的。

　　另外，在一些古老的数据库中，如果改变数据库的定义（包括增加字段、改变字段的类型、删除字段等等），那么其中所有的数据就会丢失，所以这项工作非常麻烦（我们需要先建立临时表，将数据备份出来，然后创建新表，将数据导入其中，最后再删除原来的表）。

 

但是备用字段也不能滥用，“过度设计”可能会出现一些问题：

　　 问题一：增加大量备用字段，若字段不为空，必定会浪费很多空间。

 　　问题二：由于命名的特点，如果没有完善的文档管理流程，用不了多久（可能也就是两三年），就没有人能够说清楚到底哪个字段代表的是什么意义了。就算有文档管理，这些管理工作也会比较麻烦，而且在每次使用都没有特定的规范流程，还有可能会出现冲突的情况。 

　　问题三：增加了这些备用字段就真的会够用吗？不一定，因为我们只是每个类型的字段留出几个备用，如果数量超过，或者要使用特殊的、不常用的类型的 时候，还是需要增加新的字段。比方说在上述的Person表中，我们要存储照片，那么可能就要增加一个blob类型的photo字段，这在初期设计的时候 可不一定会留出这样的备用字段。而且如果没有完善的管理，谁又能说清楚倒底哪个字段已经被使用，哪个字段还可以使用呢？到时候还不是要增加新的字段。 

 

所以对于是否需要添加备用字段，出现了一些争论，

反方：

　　1. 数据库设置备用字段无法在字段名上体现其意义，不规范，后期维护麻烦。在需要增加字段的时候如果直接addcolumn，也不会有太大工作，但能保证数据库字段的规范。虽然在启用备用字段的时候可以文档说明，但在model上对应其属性为attribute1，attribute2等，代码的可读性不强。而且，预留字段全部统一varchar，也不太合适。

　　2. 加了备用字段会影响性能

　　3.  预留字段还是会占用空间

 

正方：

　　1.  备用字段可设置为空，不会影响性能，这样备用字段在未启用前在数据库里面都是一个null 值。

　　2. 持久层的设计，数据库表结构不应轻易变更。因此应设置备用字段。启用备用字段后，只修改代码，在代码中增加注释和并文档说明即可，不需要改动数据库结构，更方便。

　　3. 如果没有备用字段，如果后期要加字段，用addcolumn的方法会改变原先的数据库存储结构，造成数据移动，移动需要时间，而且会移动到其他数据块。也就是说addcolumn会影响数据库性能，造成一些不可预知的错误。

 

 

总的来说，对于备用字段，我们应该按需设计：

　　在经过详细有效的分析之后，在数据表中只放置必要的字段，而不要留出大量的备用字段。当需要增加相关的信息时，要具体情况具体分析。
　　1）如果数量很少，而且信息的性质与原表密切相关，那么就可以直接在原表上增加字段，并将相关的数据更新进去。
　　2）如果数量较大，或者并非是原表对象至关重要的属性，那么就可以新增一个表，然后通过键值连接起来。 

 

 

共同学习，共同进步，若有补充，欢迎指出，谢谢！

转载于:https://www.cnblogs.com/dengguangxue/p/11535904.html