CouchDB中的唯一约束 [英] Unique constraints in couchdb

问题描述

是否有任何技术/建议来实施唯一约束？是的，我们可以创建唯一的密钥，但是我们不能更改密钥和密钥，而且这种方法也不适合复杂的验证（单独的唯一登录名，单独的唯一电子邮件等）。

Are there any techniques/proposals to enforce unique constraints? Yes, we can create key that's unique, but we cannot change key and keys and also this approach is not suitable for complicated validation (separate unique login, separate unique email, etc...)

例如，一个帐户应具有
个唯一的登录名和电子邮件。从此字段派生密钥
将导致
不一致：

For example, an Account should have unique login and email. Deriving a key from this fields will result in inconsistency:

key1: "[e-mail]-john", { email: "[e-mail]", login: "john"}
key2: "[e-mail]-mary", { email: "[e-mail]", login: "mary"}

看起来不错，但是：

key1: "[e-mail]-mary", { email: "[e-mail]", login: "mary"}
key2: "[e-mail]-mary", { email: "[e-mail]", login: "mary"}

糟糕，现在我们有2个登录帐户：玛丽

Oops, now we have 2 accounts with login: "mary"

推荐答案

这是CouchDB不太有趣的部分之一。我发现处理可能会更改的唯一字段的最佳方法（例如在您的用户示例中）是使用唯一值作为键的组成部分创建指针文档，然后使用它们来声明唯一值。这样做的重要部分是为主文档具有可预测的密钥，然后在保存主文档之前保存唯一的字段声明文档（并且让密钥冲突阻止主文档被保存）。

This is one of the less fun bits of CouchDB. The best way I've found for handling unique fields that can change (like in your user example) is to create "pointer" documents with the unique values as a component of the key, and then use those to let you claim unique values. The important part of doing this is having a predictable key for the primary document, then saving the unique field claim documents prior to saving the primary (and letting key conflicts prevent the primary document from saving).

为用户提供唯一的用户名和电子邮件，您的主要文档可能如下所示：

Given a user with a unique username and unique email, your primary documents might look like this:

user-1234: { username: "kurt", email: "kurt@localhost" }
user-9876: { username: "petunia", email: "[e-mail]" }

唯一字段指针看起来像这样：

The unique field pointers would look something like this:

user-username-kurt: { primary_doc: "user-1234" }
user-email-kurt@localhost: { primary_doc: "user-1234" }
user-username-petunia: { primary_doc: "user-9876" }
[e-mail]: { primary_doc: "user-9876" }

创建或更新用户将执行以下步骤：

Creating or updating a user would take these steps:

1. 复制用户文档，为生成一个密钥


2. 为每个更改后的唯一字段保存一个指针文档


3. 如果保存任何失败的内容，请停止并修复错误
>

4. 保存主要用户文档

1. Prep your user document, generate a key for it if necessary
2. Save a "pointer" document for each changed unique field
3. If saving any of those fails, stop and fix errors
4. Save primary user document

第3步将需要一些思考。例如，您将不想为未更改的字段声明唯一值。您可以，但是随后必须添加一些其他逻辑来处理您为已经拥有该值的用户声明值的情况。

Step 3 will take some thought. For instance, you won't want to try claim unique values for fields that haven't changed. You could, but then you'd have to put some additional logic in to handle a case where you're claiming a value for a user that already owns that value.

第3步也是一个使人们也能采用旧的宣称价值的好地方。例如，如果某个用户释放了用户名kurt，则可以在确认不再使用该新文档后，将其更新为指向我的新密钥。另一种方法是在声明的唯一值更改时清除它们。我不确定这会减少工作量。在我看来，保留过时的声明值是最有意义的。

Step 3 would be a good place to let people take old claimed values as well. If one user has "released" the username kurt, for instance, I can just update that particular document to point to my new key after verifying that it's no longer in use. The alternative is to clear out claimed unique values when they change. I'm not sure which would be less work, really. Leaving stale claimed values in makes the most sense to me.

此解决方案的有趣之处在于，一旦指针文件不再需要使用它们，它们就不需要使用任何东西。重新创建。您可以在用户文档上正常创建视图，并使用它们通过电子邮件或用户名查询。

The interesting thing about this solution is that you don't need to use those pointer documents for anything once they're created. You can create views as normal on your user docs, and use them to query by email or username.

此设置还允许您建立关系而不必担心级联用户密钥。我不了解您，但是系统中几乎所有其他文档都引用了我的用户文档。更改用户密钥将是一个巨大的麻烦。

This setup also allows you to do relationships without having to worry about cascading user keys. I don't know about you, but my user documents are referenced by just about every other document in the system. Changing a user key would be a massive pain in the ass.

这篇关于CouchDB中的唯一约束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！