代表bedDB中的多对多关系 [英] representing a many-to-many relationship in couchDB
问题描述
假设我正在编写日志分析应用程序。主域对象将是LogEntry。此外。应用程序的用户定义一个LogTopic，该LogTopic描述他们感兴趣的日志条目。当应用程序接收到日志条目时，它将它们添加到bedDB，并对照系统中的所有LogTopics检查它们是否符合主题中的条件。 。如果是，则系统应记录该条目与主题匹配。因此，LogEntries和LogTopics之间存在多对多关系。
Let's say I'm writing a log analysis application. The main domain object would be a LogEntry. In addition. users of the application define a LogTopic which describes what log entries they are interested in. As the application receives log entries it adds them to couchDB, and also checks them against all the LogTopics in the system to see if they match the criteria in the topic. If it does then the system should record that the entry matches the topic. Thus, there is a many-to-many relationship between LogEntries and LogTopics.
如果将其存储在RDBMS中，我将执行以下操作：
If I were storing this in a RDBMS I would do something like:
CREATE TABLE Entry (
id int,
...
)
CREATE TABLE Topic (
id int,
...
)
CREATE TABLE TopicEntryMap (
entry_id int,
topic_id int
)
使用CouchDB我首先尝试仅具有两种文档类型。我有一个LogEntry类型，看起来像这样：
Using CouchDB I first tried having just two document types. I'd have a LogEntry type, looking something like this:
{
'type': 'LogEntry',
'severity': 'DEBUG',
...
}
并且我有一个LogTopic类型，看起来像这样：
and I'd have a LogTopic type, looking something like this:
{
'type': 'LogTopic',
'matching_entries': ['log_entry_1','log_entry_12','log_entry_34',....],
...
}
您可以看到，我通过在每个字段中使用 matching_entries 字段来表示这种关系LogTopic文档，用于存储LogEntry文档ID的列表。在某种程度上可以正常工作，但是当多个客户端都试图向主题添加匹配条目时，我遇到了问题。两者都尝试乐观更新，而一次失败。我现在使用的解决方案实质上是重现RDBMS方法，并添加第三种文档类型，例如：
You can see that I represent the relationship by using a matching_entries field in each LogTopic documents to store a list of LogEntry document ids. This works fine up to a point, but I have issues when multiple clients are both attempting to add a matching entry to a topic. Both attempt optimistic updates, and one fails. The solution I'm using now is to essentially reproduce the RDBMS approach, and add a third document type, something like:
{
'type':'LogTopicToLogEntryMap',
'topic_id':'topic_12',
'entry_id':'entry_15'
}
这可行，并且克服了并发更新问题，但是我有两个保留意见：
This works, and gets past the concurrent update issues, but I have two reservations:
- 我担心我只是使用这种
方法，因为这是我在
a关系数据库中所做的。我想知道是否有一个
更好的类似于ouchDB的（轻松的？）
解决方案。 - 我的视图不再可以
在一次调用中检索
特定主题的所有条目。我以前的
解决方案允许这样做（如果我
使用include_docs参数）。
任何人都有更好的解决方案为了我？
Anyone have a better solution for me? Would it help if I also posted the views I'm using?
推荐答案
您的方法还可以。使用CouchDB并不意味着您将只放弃关系建模。您将需要运行两个查询，但这是因为这是一个联接。带有联接的SQL查询也很慢，但是SQL语法使您可以在一条语句中表达查询。
Your approach is fine. Using CouchDB doesn't mean you'll just abandon relational modeling. You will need need to run two queries but that's because this is a "join". SQL queries with joins are also slow but the SQL syntax lets you express the query in one statement.
在我使用CouchDB的几个月中，这是我发现的：
In my few months of experience with CouchDB this is what I've discovered:
- 没有模式，因此设计应用程序模型既快速又灵活
- CRUD在那里，因此，开发应用程序既快速又灵活
- 再见SQL注入
- 什么是SQL连接需要在CouchDB中进行更多工作 >
- No schema, so designing the application models is fast and flexible
- CRUD is there, so developing your application is fast and flexible
- Goodbye SQL injection
- What would be a SQL join takes a little bit more work in CouchDB
根据您的需求，我发现，couchdb-lucene对于构建更复杂的查询也很有用。
Depending on your needs I've found that couchdb-lucene is also useful for building more complex queries.
这篇关于代表bedDB中的多对多关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
