FAQs问答系统的数据库表设计的建议

在做一个模块性的设计时，应该考虑当前的背景来做，不考虑当前使用环境背景来做的设计，都是耍流氓。

1.当前的问答系统是上线的初期阶段，应该考虑需求会变动的情况，在需求变动时，应尽量避免牵一发而动全身，灵活的设计还是上上策。

在这种设计中，灵活体现在哪里呢？
比如一个场景，用户针对上传的图片需要做描述，即用户想针对自己的症状的照片加一些叙述，以便能够更好的让医生了解我当前的问题，当出现这个情况的时候，针对昨天评审结果的设计，试想一下我们会将表如何设计改变呢，情况可能如下：
a. 图片的Guid是以json格式存储的，也就是拼接在一起，这时只能推翻这张表的全部设计，重新再来
b. 再看answer和question表应该怎么改，回答也有图片或者描述时，都需要增加不同数量的字段，加减字段在系统后期时的代码层，将是致命的。

再看有info表的设计，遇到该场景该怎么改动：
a.增加图片描述，以及问题描述，当前设计不需要改动，content也可以当做描述
b.answer增加图片或者描述，直接在info表中增加type的枚举即可，方便易用

还有很多别的场景，也是一样，在需求变动的情况下，该种设计是比较灵活易用的，比如说answer和question需要做相关关联时，问题分租，答案归类分租等，以便用户更好的查找和后期的统计分期，都费用适用。

再说一下昨天针对索引优化的问题：
在具体的业务需求中，没有完美的设计，只有最适用的设计。扬长避短是设计必须要做的。
当前表的结构，单标的数据维护和拆分，比如info表中的answer数据会非常多，那么我们可以直接横向扩张，拆分出一张answer表出来，这样做索引的性能更优于在question和answer表中各添加字段的方式。

当前的情况是，我们的数据量可能还完全达不到水平拆表的程度，这种设计已经完全满足目前的问答的需求了。

综上所述，尊重当前环境以及背景下做事，才是好的选项。所有以盲目追求性能和查询最快的想法，都是异想天开，不切实际。
最后做一个佛系程序员。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69930244/viewspace-2647560/，如需转载，请注明出处，否则将追究法律责任。