我目前正在使用mysql。我发现我的架构变得异常复杂。我寻求找到一个适合我需要的新数据库：
假设我正在构建一个新闻聚合器（它从多个网站收集新闻）。然后我运行算法来确定来自不同站点的两条新闻是否实际上指的是同一个主题。我运行这个算法将新闻聚集在一起。关系如下图所示：
cluster
\--news1
\--word1
\--word2
\--news2
\--word3
\--news3
\--word1
\--word3
然后我会应用一些魔法并确定每个单词的重要性。总结每个单词的所有重要性给了我一篇新闻文章的重要性。总结每篇新闻文章的重要性给了我一个集群的重要性。
请注意，上面的集群还有子组（如按地区划分等）和类别（如体育等），我必须确定其在特定日期本身的重要性。
我过去曾使用视图来执行此操作，但我意识到视图非常缓慢。所以我通常会在实际表中插入并索引它们以获得更好的性能。如您所见，这会导致派生多个表，例如（集群，重要性），（新闻，重要性），（单词，重要性）等，这些表可能会变得非常混乱。
“重要性”指标也会发生变化。更改表、更新数据（我正在使用 TRUNCATE TABLE）然后从 null 插入变得越来越困难。
我目前正在研究像 Mongodb 这样的无模式的东西。我不需要分布式。我非常想要一些相当快的东西（可以被索引）和比传统 RDMBS 更灵活的东西。
新的
应各种人的要求，我将我的使用情况发布到这个数据库（它们不是实际的SQL查询，因为我希望这里的每个人都能理解）
TABLE word ( word_id, news_id, word )
TABLE news ( news_id, date, site .. )
TABLE clusters ( cluster_id, cluster_leader, cluster_name, ... )
TABLE mapping_clusters_news( cluster_id, news_id)
TABLE word_importance (word_id, score)
TABLE news_importance (news_id, score)
TABLE cluster_importance( cluster_id, score)
TABLE group_importance( cluster_id, score)
您可能会注意到 TABLE_word 有一个额外的 news_id 列。这是为了对应 TABLE_word_importance 列，因为同一个词在不同的文章中可能有不同的重要性（如果你熟悉 tfidf，基本上是这样的）。
所有“重要性”表现在通过平均其下方所有子实体的重要性来计算每个实体的重要性。这意味着每个集群的重要性取决于其中的所有新闻，每个新闻的重要性取决于其中的所有单词等。
TYPICAL USAGE:
1) SELECT clusters FROM db THAT HAS word1, word2, word3, .. ORDER BY cluster_importance_score
2) SELECT words FROM db BELONGING TO THE CLUSTER cluster_id=5 ODER BY word_importance score.
3) SELECT groups ordered by importance score.
正如你所看到的，我从每一层得到了很多分数，有人告诉我为此目的使用物化视图（postgresql 支持它）。但是，如您所见，这个简单的模式已经包含 8 个表（我的实际数据库包含 26 个类似的废话表，这增加了太多额外的维护层复杂性）。
注意这不是关于全文搜索。
