如何在CouchDB中为文档字段设置唯一约束？

Great question! CouchDB doesn’t include native unique constraints out of the box like relational databases do, but there are reliable workarounds to enforce uniqueness for fields such as email, emp_id, and phone_number. Let’s walk through the most practical approaches:

This is the most common method. You’ll create a view that emits the values of your unique fields as keys, then check against this view before writing any new document.

Step 1: Create a Design Document with the View #

First, define a map function that emits each unique field prefixed with its type (to avoid collisions between different fields, e.g., an emp_id that’s the same as a phone_number):

function(doc) {
  if (doc.email) emit(`email:${doc.email}`, doc._id);
  if (doc.emp_id) emit(`emp_id:${doc.emp_id}`, doc._id);
  if (doc.phone_number) emit(`phone_number:${doc.phone_number}`, doc._id);
}

Save this as a view named by_unique_key in a design document (e.g., _design/unique_constraints).

Step 2: Check Uniqueness Before Writing #

When inserting or updating a document:

• For each unique field in the document, query the view with the prefixed key (e.g., GET /your_db/_design/unique_constraints/_view/by_unique_key?key="email:user@example.com").
• If the query returns any rows, the value already exists—reject the write.
• If no rows are returned, proceed to insert/update the document.

⚠️ Note: This works well for low-to-moderate concurrency, but there’s a small window where two concurrent writes could slip through. You’ll need to handle 409 Conflict responses and recheck uniqueness if that happens.

If one of your fields (like emp_id) is a natural unique identifier, you can use it directly as the document’s _id field. CouchDB guarantees that _id values are unique across the database—any attempt to insert a document with an existing _id will return a 409 Conflict.

For example, when creating a new employee document:

{
  "_id": "emp_id:12345",
  "emp_id": "12345",
  "email": "john.doe@company.com",
  "phone_number": "555-1234"
}

This approach is simple and bulletproof for the field you map to _id, but it only works for one unique field. If you need uniqueness across multiple fields, combine this with the view method above.

To move the uniqueness check logic to the server (reducing client-side code), use a CouchDB Update Function. This function runs on the server when you send a request to it, allowing you to validate uniqueness before committing the document.

Example Update Function #

Save this in your design document under updates/validate_unique:

function(doc, req) {
  // Parse the incoming document data
  const newDocData = JSON.parse(req.body);
  
  // Helper function to check if a unique key exists
  const checkUnique = (prefix, value, excludeDocId) => {
    const key = JSON.stringify(`${prefix}:${value}`);
    const result = get(`/${req.db}/_design/unique_constraints/_view/by_unique_key?key=${key}`);
    return result.rows.some(row => row.value !== excludeDocId);
  };

  // Check each unique field
  if (newDocData.email && checkUnique("email", newDocData.email, doc?._id)) {
    return [null, { error: "conflict", reason: "Email already exists" }];
  }
  if (newDocData.emp_id && checkUnique("emp_id", newDocData.emp_id, doc?._id)) {
    return [null, { error: "conflict", reason: "Employee ID already exists" }];
  }
  if (newDocData.phone_number && checkUnique("phone_number", newDocData.phone_number, doc?._id)) {
    return [null, { error: "conflict", reason: "Phone number already exists" }];
  }

  // Prepare the document (create or update)
  const finalDoc = doc ? { ...doc, ...newDocData } : { ...newDocData, _id: req.uuid };
  return [finalDoc, { ok: true }];
}

Use the Update Function #

Instead of directly POSTing to the database, send your document data to the update function endpoint:

POST /your_db/_design/unique_constraints/_update/validate_unique

The function will handle validation and return an error if any unique field is duplicated.

For high-traffic systems where even the small race condition in the view method is unacceptable, add a middleware layer (e.g., a Node.js API) between your clients and CouchDB. This layer acts as a gatekeeper:

1. Receive write requests from clients.
2. Use a distributed lock or queue to serialize checks for unique fields.
3. Query CouchDB’s unique view to confirm no duplicates exist.
4. Only forward the write to CouchDB if validation passes.

This adds complexity but eliminates race conditions entirely.

No matter which method you choose, CouchDB’s distributed nature means you must handle 409 Conflict responses. Even with server-side checks, concurrent writes can still cause conflicts. When this happens:

1. Fetch the latest version of the conflicting document.
2. Recheck the uniqueness of your fields against the current database state.
3. Retry the write if the uniqueness constraint is still satisfied.

内容的提问来源于stack exchange，提问作者Akshay Sood