请教一个简单但一般不会注意到的设计问题,跟贴给分,请多多指教

Question

数据库表table1(a, b, c, d, e, f, g, h, i, j, k, l, m, n)
a为主键
列n常常被修改,b, c, d, e, f, g, h, i, j, k, l, m,很少修改.请问我是不是需要把表修改为:
(a, b, c, d, e, f, g, h, i, j, k, l, m)
(a, n)个人觉得分为两个表有冗余, 但别人说可以提高性能.请问这样是不是真的能提高性能?

Answer 1

大表该不该划分为小表原则是把业务关系紧密的合并在一起,并不紧密的松开.比如一个有60个字段的表(已经范式过的),想要不拆分表的情况下,无论你如何去优化它,最多只有从索引上下手,这种情况下,就需要考虑把不经常需要使用的表进行划分.划分的分界,一般关注在大数据类型字段上,这取决于你的业务.如果是一个文章管理系统,这个大字段访问频率非常之高,肯定是不能拆分的,但如果这是一个参考数据,比如历史记录文档(几百年不用一次的那种),就应该划分到另外一个表中了.也就是说:即使是一对一的表,其中的字段也有重要与不重要之分,有一些不能够舍去,但又不常用的字段分配到另一张表中.同时,这对于开发人员来说,概念也比较清晰.实际上这是一种不应该划分的表.是否需要划分取决查询的方式,这个要根据系统的需求进行详细的分析.对于查询比较频繁的部分,可以从扩展性与可维护性还有性能上综合考虑.如果性能要求高,则需要应用反范式来组合表,最终达到一个三者间的平衡就可以了(高性能的系统一般很复杂).所以,如果着重于扩展性与可维护性,那么就不要动它.注意:上面说的仅限于一对一方式的考虑,其它关系有其它的考虑方法.有一种支持逐步渐进的开发方法是:在开发之前,想要都规划好是不可能的,可以考虑先量分割为比较细的元表,然后根据性能要求,逐渐地对表进行合并,然后手工在应用程序中进行相应的更改.这种开发模式任务不算大,但也不算小了.
如果有代码生成器与O/R Mapping工具,这种任务量就会减小.

Answer 2

你说的这种情况，我觉得应该视具体需求而定吧对于数据库的设计大概有两种方法：
    一是一开始就把一个对象的所有属性权放到一张表里，然后通过保证函数依赖及无损联结进行分解，显然，这只是增加了数据库的更新性能，却降低了数据库的查询性能，于是我们应该参照数据库的反规范化设计，寻求一个最佳结合点。
    二是一开始就按照E-R 的九部设计模式设计出E—R图，然后再将E-R 模型转换为数据库的表结构。

Answer 3

经常修改的字段通常不应该是作索引的字段
所以就查询而言效率未必有什么提升。只是频繁修改数据会造成表空间膨胀很快而已，这样会对数据查询有影响，只要做好数据库经常性的维护，理论上没有什么影响。就如上面有人说的，至于分表的一对一设计问题，具体要看业务逻辑的需求，不能因数据变更的频繁程度这一说法来简单划分。不管怎样 ，划分表后总是要做联合查询的，多了IO，HASH肯定也是损失性能的。至于优劣，真的需要看具体业务