database - primary - Pros y contras de usar md5 hash de URI como clave principal en una base de datos
uuid as primary key (7)
A menudo, muchas URL diferentes apuntan a la misma página. http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/ . https://example.com/ etc.
Esto podría o no ser un problema para ti.
Estoy construyendo una base de datos que almacenará información sobre una variedad de objetos (como documentos científicos, especímenes, secuencias de ADN, etc.) que tienen presencia en línea y pueden identificarse mediante una URL o un identificador como un DOI. . El uso de estos GUID como la clave principal para el objeto parece una idea razonable, y he seguido delicioso y Connotea al usar el hash md5 del GUID. Verá el hash md5 en la barra de estado de su navegador si pasa el mouse sobre los botones de edición o eliminación en una deliciosa marca de libro de Connotea. Por ejemplo, el marcador para http: // stackoverflow / es
http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d
donde e4a42d992025b928a586b8bdc36ad38d es el hash md5 de http: // stackoverflow / .
¿Alguien tiene puntos de vista sobre los pros y los contras de este enfoque?
Para mí, una ventaja de este enfoque (en lugar de usar una clave primaria autoincrementada generada por la base de datos en sí) es que tengo que hacer muchos enlaces entre objetos, y al usar hashes md5 puedo almacenar estos enlaces externamente en un archivo (digamos, como resultado de la extracción / raspado de datos), luego impórtelos a granel en la base de datos. Del mismo modo, si la base de datos debe reconstruirse desde cero, las URL a los objetos no cambiarán porque usan el hash md5.
Me agradaría cualquier idea sobre si esto parece sensato, o si hay otras (¿mejores?) Formas de hacerlo.
Quizás este documento es algo que quieres leer:
Varias cadenas pueden producir el mismo hash md5. Las claves primarias deben ser únicas. Entonces, usar el hash como clave principal no es bueno. Mejor es usar el GUID directamente.
Es un GUID adecuado para su uso en una URL. Por supuesto. Aquí hay un GUID (en realidad, un UUID) que creé usando Java: 1ccb9467-e326-4fed-b9a7-7edcba52be84
La url podría ser:
http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84
Es largo pero perfectamente utilizable y logra lo que describes.
MD5 se considera obsoleto, al menos con fines criptográficos, pero yo sugeriría que solo se use md5 para compatibilidad con versiones anteriores de material existente. Deberías tener una buena razón para ir con md5 cuando tenemos otros algos hash que no están (al menos) rotos.
Problemas que veo con el enfoque:
- Duplicar objetos, porque el identificador de url es diferente (como se menciona)
- Cambio de URL
El último es el que podría ser importante; esto podría hacerse simplemente como un remove y un add. Es decir, si estos identificadores nunca son visibles / almacenables fuera de la base de datos. (Como un componente de una URL)
Supongo que estos no serán un problema para los DOI.
¿Cómo funcionaría con una configuración de identificación entera no autónoma, pero donde el agente insertor sin conexión crea los números? (¿Puede usar un rango de números dedicado, quizás?) ¿Podría haber un problema con la duplicación si dos usuarios agregan de forma independiente la misma URL?
md5 hash no es único así que no lo use como clave principal. No puede usar valores no únicos para la clave principal. Hay menos posibilidades de que se produzca una colisión clave, pero si tiene una base de datos bastante grande con miles de millones de filas, todavía hay posibilidades de que se produzca una colisión. Si insiste en usar hash como clave principal, use otro mejor hash.
Después de navegar stackoverfow un poco más encontré una pregunta anterior Ventajas y desventajas de las claves de base de datos GUID / UUID que cubren gran parte de este terreno.
Está perfectamente bien.
La colisión accidental de MD5 es imposible en todos los escenarios prácticos (para tener un 50% de probabilidad de colisión, tendría que cortar 6 mil millones de URL por segundo , cada segundo, durante 100 años).
Es una posibilidad tan improbable que tienes una probabilidad un billón de veces de que tus datos se dañen debido a una falla de hardware no detectada que por una colisión real.
A pesar de que existe un conocido ataque de colisión contra MD5, las colisiones malintencionadas intencionadas son actualmente imposibles contra las URL hash.
El tipo de colisión que necesitarás colisionar intencionalmente con un hash de otra URL se llama ataque previo a la imagen . No se conocen ataques previos a la imagen contra MD5. A partir de 2017, no hay investigación que se acerque siquiera a la viabilidad, por lo que incluso un atacante determinado y bien financiado no puede calcular una URL que jerarquice un hash de cualquier URL existente en su base de datos.
El único ataque de colisión conocido contra MD5 no es útil para atacar claves tipo URL. Funciona al generar un par de blobs binarios que colisionan solo entre sí . Los blobs serán relativamente largos, contendrán NUL y otros bytes no imprimibles, por lo que es muy poco probable que se parezcan a algo parecido a una URL.