database-design - que - mongodb español
¿Cuál es la mejor práctica al crear documentos ID en couchdb? (6)
Todos sabemos que para las bases de datos relacionales, es una buena práctica usar identificadores numéricos para la clave principal.
En couchdb, la ID predeterminada que se genera es un UUID . ¿Es mejor seguir con el valor predeterminado o utilizar un identificador fácil de recordar que el usuario utilizará en la aplicación?
Por ejemplo, si estuviera diseñando la base de datos stackoverflow.com en couchdb, ¿usaría el slug preguntas (por ejemplo, what-is-best-practice-when-creating-document-ids-in-couchdb) o un UUID para cada documento? ?
El _id se usa mucho en el interior de CouchDB y cualquier costo extra de hashing va a ralentizar un montón de internos así que es mejor seguir con el UUID provisto.
La clave primaria en un DB nunca debería tener ningún "significado", excepto tal vez codificar la secuencia. Es posible que desee cambiar el SLUG pero no la clave principal.
Puede haber un buen argumento para usar algo que comience con una marca de tiempo para tener un orden inherente en sus claves. A menudo uso "% f @% s"% (time (), hostname ()) para obtener claves únicas y ordenadas. (Esto solo funciona si su implementación time () nunca devuelve el mismo valor dos veces).
Para otras cosas (por ejemplo, imágenes), donde quiero evitar duplicados, a menudo uso sha (datos) como clave.
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 más larga es, depende de:
Costo de cambiar ID Vs ¿Cuán probable es que la identificación cambie?
Bajo costo de cambio y probabilidad de cambiar la identificación
Un ejemplo de esto podría ser un blog con un diseño desnormalizado, como el blog de jchris ( código de sofá disponible en 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.
El alto costo de cambiar la identificación y una identificación que nunca cambiará
Un ejemplo de esto es cualquier diseño de base de datos que esté altamente normalizado y use identificadores de autoincremento. .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 de base de datos 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é tan probable es que cambie la identificación?
Si no quiere usar UUID probablemente ya tenga una idea de qué ID quiere 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
Los puntos de referencia muestran 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.
¿Harás muchas inserciones a granel?
Si es así, es mejor usar UUID incrementales para un mejor rendimiento.
Mira esta post sobre inserciones masivas. Damien Katz comenta y dice:
"Si quieres tener los tiempos de inserción más rápidos posibles, debes dar los valores ascendentes del _id, así que obtén un UUID e increméntalo en 1, de esa forma siempre se insertará en el mismo lugar en el índice, y será amigable con el caché una vez que estés tratar con archivos de mayor tamaño que la RAM. Para una forma más fácil de hacer lo mismo, numere secuencialmente los documentos pero hágalo de forma fija con relleno para que ordenen correctamente, por ejemplo, "0000001" en lugar de "1".
Podría ir con el Id. De CouchDB (UUID) predeterminado, como decía en la documentation las razones principales para usar el UUID predeterminado son las siguientes:
- Los UUID son números aleatorios que tienen una probabilidad de colisión tan baja que todos pueden generar miles de UUID por minuto durante millones de años sin crear un duplicado. Esta es una gran manera de garantizar que dos personas independientes no puedan crear dos documentos diferentes con la misma ID.
- La replicación de CouchDB le permite compartir documentos con otras personas y el uso de UUID garantiza que todo funcione.
Ahora, por otro lado, si confías en el servidor (CouchDB) para generar el UUID y terminas haciendo dos solicitudes POST porque la primera solicitud POST se destruyó, puedes generar dos documentos y nunca averiguar sobre el primero porque solo se informará el segundo, por lo tanto, es una buena idea generar tus propios UUID para asegurarte de que nunca terminarás con documentos duplicados, pero definitivamente iré con UUID a menos que específicamente necesites lo contrario. documenta .
Viniendo desde el punto de vista de una base de datos relacional, me tomó un tiempo encontrar el sofá. Pero la verdad es lo opuesto a la respuesta de aceptación;
En lugar de utilizar un uuid predeterminado, generar una identificación inteligente puede ser de gran ayuda para recuperar y ordenar datos.
Supongamos que tiene una base de datos de películas. Todos los documentos se pueden encontrar en algún lugar debajo de la URL / películas, pero ¿dónde exactamente?
Si almacena un documento con _id Jabberwocky ({"_id": "Jabberwocky"}) en su base de datos de películas, estará disponible en la URL / películas / Jabberwocky. Entonces, si envía una solicitud GET a / movies / Jabberwocky, obtendrá el JSON que conforma su documento ({"_id": "Jabberwocky"}).
http://guide.couchdb.org/draft/documents.html
Consejo de rendimiento: si solo está utilizando los ID de documentos generados de forma aleatoria, no solo está perdiendo la oportunidad de obtener un índice gratuito, sino que también está incurriendo en gastos generales para generar un índice que nunca va a utilizar. utilizar. ¡Así que use y abuse sus ID de documento!
https://pouchdb.com/2014/05/01/secondary-indexes-have-landed-in-pouchdb.html
Me doy cuenta de que esta es una pregunta largamente respondida, pero hay otra consideración importante para aquellos que descubren el problema. Cuando se elimina un documento, todo lo que sabes sobre él es la identificación. Escribir, ya sea explícito ( type:foo ) o implícito (pato) no funciona. Por lo tanto, no puede suscribirse a los cambios para doc.deleted===true && doc.type==foo , porque después de la eliminación, doc.type===undefined . Un valor _id que puede decodificar post-hoc es útil, particularmente si su código de cliente necesita ser de otro modo sin estado (y por lo tanto no puede almacenar en caché una lista de _id s por tipo).