couchdb - 表示 couchDB 中的多对多关系

Question

假设我正在编写一个日志分析应用程序。主域对象是 LogEntry。此外。应用程序的用户定义一个 LogTopic，描述他们感兴趣的日志条目。当应用程序接收日志条目时，会将它们添加到 couchDB，并根据系统中的所有 LogTopics 检查它们，看看它们是否符合主题中的条件。如果是，那么系统应该记录该条目与主题匹配。因此，LogEntries和LogTopics之间存在多对多的关系。

如果我将其存储在 RDBMS 中，我会执行以下操作:

CREATE TABLE Entry (
 id int,
 ...
)

CREATE TABLE Topic (
 id int,
 ...
)

CREATE TABLE TopicEntryMap (
 entry_id int,
 topic_id int
)

使用 CouchDB，我首先尝试只使用两种文档类型。我有一个 LogEntry 类型，看起来像这样:

{
  'type': 'LogEntry',
  'severity': 'DEBUG',
  ...
}

我有一个 LogTopic 类型，看起来像这样:

{
  'type': 'LogTopic',
  'matching_entries': ['log_entry_1','log_entry_12','log_entry_34',....],
  ...
}

您可以看到，我通过在每个 LogTopic 文档中使用 matching_entries 字段来存储 LogEntry 文档 ID 列表来表示关系。在某种程度上，这工作得很好，但是当多个客户端都尝试向主题添加匹配条目时，我会遇到问题。两者都尝试乐观更新，但其中一个失败了。我现在使用的解决方案本质上是重现 RDBMS 方法，并添加第三种文档类型，例如:

{
  'type':'LogTopicToLogEntryMap',
  'topic_id':'topic_12',
  'entry_id':'entry_15'
}

这可行，并且解决了并发更新问题，但我有两个保留:

1. 我担心我只是在使用这个方法，因为这就是我要做的关系数据库。我想知道是否有更像 couchDB(轻松？)解决方案。
2. 我的观点不能再检索 a 的所有条目一次通话中的特定主题。我的以前的解决方案允许(如果我使用了 include_docs 参数)。

谁有更好的解决方案给我？如果我也发布我正在使用的 View 会有帮助吗？

Answer 1

你的方法很好。使用 CouchDB 并不意味着您将放弃关系建模。您将需要运行两个查询，但那是因为这是一个“联接”。使用联接的 SQL 查询也很慢，但 SQL 语法允许您在一条语句中表达查询。

根据我几个月的 CouchDB 经验，我发现了以下几点:

1. 没有架构，因此设计应用程序模型既快速又灵活
2. CRUD 存在，因此您的应用程序开发既快速又灵活
3. 再见 SQL 注入(inject)
4. 在 CouchDB 中 SQL 连接需要做更多的工作

根据您的需求，我发现 couchdb-lucene 对于构建更复杂的查询也很有用。