求助“知识点”的数据库设计

Question

少用关联,大数据关联是最没有效率的一件事,你应该多了解一下NoSQL的知识

Answer 1

先不讨论nosql，200万的数据对关系型数据库来说也不是很大的数量。
看了你的设计，觉得在知识点栏目和内容三者关系上和你意见有些不同，暂且不说你的栏目内容表是否符合三范式设计，仅从实际出发，内容应该和知识点的关系更为密切，而且一个知识点可以对应多个内容，从生活中将就是对于同一个观点，不同的人可以发表不同的论述。而栏目仅仅是承载这些知识点的载体，与内容并无直接关系，所以把内容划入栏目内容表，貌似有点差强人意。这仅代表我个人看法，如有错误还请见谅和指正。

Answer 2

有现成的wiki系统，就不要开发了。何况你们的技术又那么业余。

Answer 3

lz所谓的“知识点”，就是NoSql所要解决的“无模式数据库”问题。用关系数据库去套，就是个麻烦死也无法让用户满意的可行性问题，用NoSql则是正好切合。

Answer 4

比如说有一个数据“表”叫做“知识”的，它的输入数据可能是这样：[{"关键名称":"招商银行",
  "关键字":["招商银行","银行"],
  "栏目":[{"分组名称":基本情况,
               "具体栏目":[...........]
              }]
 },
 {"关键名称":"设备系统",
  "关键字":["设备管理","生产"],
  "台账":[{"设备编号":"0110202A", ”名称":"NP1型吹风机","厂家":"....", "状态":"良好"，"功率":1500,"单位":"w",...},
              {"设备编号":"0382828B","名称":"XY型控制箱","状态":"运转","尺寸":100,"箱内设备":[.....}}
            }
 }
]显然，这里随时加入不同的所谓“知识点”，每一个知识点内部的构造都不同。将来如果需要查询，例如需要按照“功率大于1500w”做为索引条件进行查询，仍然可以直接找到“NP1性吹风机”而跳过“招商银行”。
其实“知识点”这类是cms系统或者国内的oa系统的称呼。这是没有NoSql概念的10年前的称呼。

Answer 5

lz所谓的“栏目、栏目内容、栏目分组”之类的，可能是基于它的研究的数据恰好是局限于一个小cms系统的缘故。然后可以举出无数种实际的无模式文档数据库的例子，比如说亚马逊的系统要展示商品，你可以动态地看到各种商品分类。做为采购人员，比如说他采购了一批吹风机，于是他就可以在采购录入单上“当时就”加入“功率”这个属性；而如果他采购的是CPU，他就可以“当时就”加入“主频”这个属性。而且一个商品如果有需要拆分的部件，还可以“当时就”录入。于是录入商品数据时，可以随意增加字段（包括做为数据表的字段），而不需要预先定义字段类型。不同的记录完全可以有截然不同的字段类型。这就是NoSql的作用。如果你有这个知识，你就不用针对什么cms做“知识点”之类设计了。你可以把整个知识体系扩展到一个新的实用的高度，随时设计出灵活性强、性能堪比亚马逊和淘宝网的“无模式”知识数据库。

Answer 6

low b才会为了这么个p事从头设计nosql半天wiki早上线了。。

Answer 7

Mediawiki其实是个好主意。你的项目栏目标的更新时间只能记录最近一次更新，但Mediawiki已经自带了历史记录的功能，参见维基百科。Mediawiki也可以给用户分配权限，可以只允许某些人修改文章（就是你说的知识点）。Mediawiki的搜索功能可能不够强，就维基百科的体验来看，应该不能搜比如网址以.com结尾的所有知识点。
如果就楼主的关系数据库而言，我认为楼主的设计没有问题。楼主的设计允许一个栏目有子栏目，栏目里有内容。一个知识点通过栏目，可以用相同名称的内容。比如招商银行->基本情况->Logo，可能企业文化里也有一个Logo。

Answer 8

确实没有NoSql的知识。要实现的功能也比较简单，也就没想为这个去从头学一回。
不过听大家一说，还真是应该学习NoSql。