La seule façon de renforcer l'unicité dans CouchDB est le champ _id. Je crois que la meilleure pratique pour d'autres choses qui ont besoin d'unicité est de permettre au client de le stocker, puis de vérifier l'unicité en tant que programme externe (ou tâche thread, ou cron, etc.) puis de réagir à cela. Par exemple, une vue de carte/réduction peut facilement produire un nombre de valeurs de champ identiques, donc la recherche de champs avec count > 1 est facile. Ensuite, corrigez les doublons que vous trouvez.
Vous pouvez même traiter cela comme un simple flux de travail avec des étapes de demande/rejet ou de demande/approbation. Stocker le document initial, mais il n'est pas officiel jusqu'à e.g. il a "confirmed":true. Il reçoit uniquement une confirmation après que votre vérificateur hors ligne a effectué les vérifications ci-dessus.
Je pense que dans les applications réelles, les personnes qui développent avec CouchDB reportent les contraintes d'unicité, pour la même raison que les gens essaient de ne pas optimiser prématurément. Vous remarquerez probablement que 99% des utilisateurs saisissent toujours une adresse e-mail unique, alors essayer d'imposer l'unicité tout le temps crée juste un problème pour vous-même dont vous n'avez pas besoin.