一个数据库设计的难题

Question

问题比较复杂，尽可能简化描述

比如一个存储文章的数据表，数据存储用的是mongodb

1、有不确定列，比如点击率、内容、标题、回复、用户uid，利的数目不确定，可能十几个，也可能上百个。可能增加，也可能减少，是动态的。

2、每个列存储的数目不确定，比如回复这个字段，可能有上百万，也有可能只有1个。

3、每个字段需要能存储版本。比如内容这个字段，可能存在多个版本，版本1、版本2、版本3。版本数目多少不确定。

我是这样设计的

1、数据表：data。存储文章的基本信息。比如文章添加时间，文章发布状态等。
2、字段表：field。存储具体的字段内容，比如回复、内容、标题。
3、还有一个数据表：version。存储版本。每个版本的具体内容依然存储在 field 里面

目前的问题：

1、存储是没问题的。比如我查询一篇文章的回复、内容，都能查询。
2、性能有问题。比如分页，一页列出25条。每条需要在列表列出一些数据给用户。比如标题、内容、时间等等。大概7个字段。加起来就是：25*7=174个查询，查询花费了10秒左右。
如果解决这个问题，可能需要把这些数据提前写入一份放到data表。也就是反范式。比如这样：

field:{
    title:'标题',
    content:'内容',
}

存放这么一些冗余数据到data表里面。

3、搜索的问题。感觉还是存在一些功能的局限和性能问题。

目前整体来说，感觉设计很复杂，代码写得很累，问题层出不穷。
不知道数据库设计问题还是说mongodb不适合存储这样的数据。
如果是你，你会怎么设计这个数据库呢

Answer 1

1.有不确定列--->这个是没有必要的，必须的列应该相对固定的，如果不固定，从几十个到几百个，你呈现数据的时候怎样呈现？
你都不确定有哪些列，你前端页面怎么写？
真要有一些可有可无的字段，你可以统一把它存在一个字段或另一个表中。

2.比如回复这个字段，可能有上百万-->回复的内容不可能和存文章的表是同一个吧？
回复当然是需要独立的一个表。
当一个字段需要存多个结果时，一般这个字段的内容会独立到另一个表中。

3.虽然 mongodb 没有像关系型数据库那么多限制，但基本的设计我觉得还是得按关系型数据库来。
你把所有东西都放到一个表中，你批量查询的时候是应该比较快的，但你想精确查找的时候可能很麻烦，还有就是写入也可能很麻烦。
比如回复，如果你回复的内容是存在文章表中的“回复”字段的话，每次添加一条回复的时候，你得把原数据先查出来，再把回复数据的内容拿出来，还需要循环一遍看回复的内容有没有重复。