No soy un experto en sofá, pero después de investigar un poco, esto es lo que encontré.
La respuesta simple es usar UUID a menos que tenga una buena razón para no hacerlo.
La respuesta larga es, depende de:
costo de cambiar ID Vs ¿Qué tan probable es el ID para cambiar
bajo costo de cambiar y es probable que cambie ID
Un ejemplo de esto podría ser un blog con un diseño desnormalizado como jchris' blog (sofa code available on git hub).
Cada vez que otro sitio web enlace a una publicación de blog, esta es otra referencia a la identificación, por lo que el costo de cambiar la identificación aumenta.
Alto coste de cambio de ID y un ID que nunca cambiará
Un ejemplo de esto es cualquier diseño DB que está altamente normalizado que utiliza identificadores de incremento automático. Stackoverflow.com es un buen ejemplo con sus Id. De pregunta de incremento automático que puede ver en cada URL. El costo de cambiar la ID es extremadamente alto ya que todas las claves extranjeras tendrían que actualizarse.
¿Cuántas referencias, o "claves foráneas" (en lenguaje DB relacional) habrá para la identificación?
Cualquier "clave externa" aumentará en gran medida el costo de cambiar la ID. Tener que actualizar otros documentos es una operación lenta y definitivamente debe evitarse.
¿Qué posibilidades hay de que cambie la identificación?
Si no desea utilizar UUID probablemente ya tenga una idea de qué ID desea usar.
Si es probable que cambie, el costo de cambiar la ID debe ser bajo. Si no es así, elija una ID diferente.
¿Cuál es su motivación para querer usar una identificación fácil de recordar?
No digas rendimiento.
Benchmarks show que "las búsquedas de teclas de vista de CouchDB son casi, pero no del todo, tan rápidas como las búsquedas directas de documentos". Esto significa que tener que hacer una búsqueda para encontrar un registro no es gran cosa. No elija identificadores amigables solo porque puede hacer una búsqueda directa en un documento.
¿Va a hacer muchas inserciones a granel?
Si es así, es mejor usar UUID incrementales para un mejor rendimiento.
Consulte este post sobre inserciones a granel. comentarios y dice Damien Katz:
"Si usted quiere tener el más rápido posibles tiempos de inserción, debe dar valores ascendentes de _ID, a fin de obtener un UUID ay se incrementará en 1, de esa manera siempre insertando en el mismo lugar en el índice, y siendo caché de usar una vez que se trata de archivos de más de RAM. para un manera más fácil de hacer lo mismo, simplemente número secuencial de los documentos, pero que sea de longitud fija con relleno tan que ordenan correctamente, "0000001" en lugar de "1", por ejemplo. "
Esta respuesta parece basa en la idea de que la prevención de conflictos es siempre deseable; sin embargo, a veces los conflictos son una parte natural del dominio del problema y, en lugar de simplemente evitarlos, deben detectarse y resolverse de manera proactiva. En tales casos, una identificación natural es una excelente opción. Por ejemplo, no use el título de una publicación de blog como ID en un sistema multiusuario masivo, pero sí use el nombre de dominio totalmente calificado y la dirección IP al modelar registros de direcciones DNS. – user359996
Este artículo explica bien el impacto de los UUID aleatorios en el rendimiento de CouchDB http://blog.inoi.fi/2010/11/impact-of-document-ids-on-performance.html – Lebugg
Después de haber utilizado CouchDB en varias fuentes comerciales y de código abierto proyectos, estoy totalmente en desacuerdo con esta respuesta. No tiene en cuenta cómo funcionan las ID en Couch (inmutable, utilizado para la clasificación, debe ser único en toda la base de datos, importancia para la replicación, etc.). – theDmi