数据表设计的思考

在学习sql的时候，强调避免数据冗余，在软件设计的时候，强调查询性能。然而规范化设计数据表往往与程序性能是冲突的，这就需要在规范和性能两个方面做好取舍.

      规范的数据表的设计，要求避免数据冗余，同样含义的数据不应该出现两次，能够通过表连接计算得到的数据不应该设置为新的字段.这样的话，存储空间可以得到最大的节省，不过最大的优点还是维护的方便，表与表之间相对独立，仅仅通过外键关联，增强了增删改的效率.

      然而一旦造成了数据冗余，破坏了表的独立性，麻烦的问题会接踵而至。我在设计论坛的时候就遇到了这样的问题。在查询帖子的时候，我想显示在界面上的是用户的昵称而不是用户的id，但是考虑到为了获得一个昵称而把用户表关联起来查询会极大的降低查询的效率，所以我把用户昵称设计为一个字段(助查字段)附在帖子表上，这样查询的时候可以直接读取而不用每次都要重新查询了。然而，麻烦的问题来了，当用户改变昵称的时候，原先在帖子表中额外存储的昵称不能得到更新，这就造成了数据不一致、数据垃圾，这可万万不行.于是我想到可以用触发器来解决这个问题：当用户更新昵称的时候，对应的帖子表中的昵称也跟着更新，这下子可不会有问题了吧。一个两个确实不会有问题，但是当冗余字段较多时，维护将变得非常麻烦，并且可扩展性很差，好像每个字段都是为了查询的方便临时创建的，如果明天我不想这么查询了，怎么办？又要删除字段，重写触发器，最终只会把数据库整的一团糟.而且对于团队开发来说，编写查询程序的人一般是没有权限操作数据库的，这么可以随便让他创建一个冗余字段呢？考虑到这些问题，我决定取消冗余的字段，采用多表查询的方法.

      于是我抱着这样的处理方案百度一下，看看别人是怎么处理这样的问题的。发现我第一次使用的设置冗余字段的方法并非无可取之处，于是我又仔细思考的这一问题，总结出了以下几点.

1.     设置助查字段是解决查询效率问题的最后的方法。只有在使用数据结构和算法无法实现性能的突破时才会采用这种非常规的方法。

2.     使用缓存技术解决查询效率问题.在程序的时候可以将数据表将会关联的枚举性的表加载到内存中，建立散列表，通过哈希映射避免数据表关联.比如在第一次查询电影类型的时候，可以将电影类型枚举表加载到内存中，建立一种映射，这样就不用每次读取类型id的时候再去搜索相应的类型了，而且这样的算法也具有可扩展性.

3.     建立索引，通过索引，可以大幅度提高查询效率，而且维护索引的开销要比维护助查字段的开销小的多.

4.     既然要设计助查字段，就不要偷偷摸摸的使用而应该大大方方的正规化的使用，建立系统性的使用和维护方案(一般采用触发器来维护)，进行严格的使用限制。这样的做法，至少对别人、对数据库来说是负责任的。

又回到了论坛的设计问题，是否应该在帖子表中建立一个更新时间字段是一个值得讨论的话题，不过现在我心中有数了：可以使用，因为发一个帖子需要使用触发器做很多事情，更新帖子是顺手牵羊，优化查询效率.