设计数据库时，【视图的使用】和【数据表冗余数据】的小结

最近在做一个相对复杂的整站，某个页面有相对复杂的业务逻辑，出现了反复bug反复修改的情况，甚至是需要将之前做的一些数据表、存储过程、页面进行修改。

这2天在总结这个情况时，也想起以前遇见过的一些“问题”的讨论。

确定需要提醒自己：视图要用，而且确实可以简化过程。（今早决定，手上的这个整站，干脆直接推翻掉不对的地方，重新写）

下面的内容，仅供参考。

如有不对，请各路大神指点。

一、视图的使用

之前对于视图的了解，仅仅是自己的总结：一段查询代码，将数据表根据需要查询出来，供查询使用；为了数据一致性，修改数据的对象是基表。

实际过程中发现，很多页面其实有复杂的处理逻辑（比如两表关联），更麻烦的是多重关联、多重验证。

而视图的使用，可以将这些复杂的关联、验证先“封装”起来；实际处理时，需要面对的就只剩下很小一部分，思路会清晰很多，bug的可能性会大大降低。

二、数据表冗余数据

以前也跟人讨论过，冗余数据的存在是否合理；当时认为冗余数据有就有吧，无所谓，有时候看起来更加方便。

目前看来，这个观点需要推翻掉。

如果冗余的话，后期在修改字段值、验证数据正确性时，会比较麻烦。并且可能影响其他逻辑的处理。

三、解决思路

1、建立数据库时，能不冗余还是不要冗余的好；如果出现其他原因需要冗余，使用视图来解决。

2、视图和数据表的对应关系，不仅是一对一，实际业务中更可能的是“多对一”：