foreign - Android: use el UUID como clave principal en SQLite

sqlite primary key autoincrement

Question

Mi aplicación debe sincronizarse con otros usuarios de la aplicación (en sus propios dispositivos). También quiero apoyar la edición sin conexión, que se sincroniza con los otros usuarios de colaboración cuando el usuario se conecta a Internet.

Entonces, el Usuario A cambia (mientras está fuera de línea) algunos datos (en otras palabras, actualizará las entradas de la base de datos) o agrega nuevos registros a la base de datos. Cuando el Usuario A se conecta a Internet, todos los cambios y nuevos registros se entregan a los otros Usuarios colaborativos. Por lo tanto, el Usuario B obtendrá los cambios / actualizaciones y puede insertarlos / actualizarlos en la base de datos de dispositivos locales del Usuario Bs.

Pero necesito asegurarme de que los identificadores de las entradas de la base de datos sean únicos a lo largo de todo el sistema. Por lo tanto, necesito usar algo como UUID.

Mi pregunta: ¿es una mala idea usar un UUID (String / Varchar) como clave principal en una tabla de base de datos SQL en lugar de un número entero que se incrementaría automáticamente?

Supongo que habrá problemas de rendimiento mediante el uso de cadenas (un UUID tiene 36 caracteres) como clave principal.

Supongo que indexar uuids en lugar de enteros lleva más tiempo (comparar cadena versus comparar números enteros). También creo que cuando estoy usando UUID, cada vez que se inserta una nueva entrada / registro de base de datos la base de datos necesita reindexar la columna de clave primaria, ya que el índice de clave primaria ya no está ordenado (que sería cuando yo usaría la clave primaria de incremento automático de enteros, porque cada registro futuro se agrega al final, porque la nueva clave primaria autoincrementada siempre es el número más grande hasta el momento, por lo que el índice estará automáticamente en orden ordenado). Lo que también tengo que hacer es UNIRSE a más de 2 - 3 tablas. También creo que la comparación de cadenas en JOINS en lugar de enteros ralentizaría la consulta de la base de datos.

Sin embargo, no puedo ver ninguna otra posibilidad de implementar dicho sistema de sincronización colaborativa, así que debo usar UUID, ¿no?

Otra posibilidad sería usar una clave primaria de incremento automático entero y usar una segunda columna uuid. Entonces, para trabajar en el dispositivo local de los usuarios, usaría esta clave primaria (entero) para UNIRSE, etc., mientras que usaría la columna uuid para sincronizar con los otros usuarios.

¿Qué piensan de ese enfoque o, en su opinión, de mucho trabajo, ya que no esperarán un gran problema de rendimiento al usar UUID directamente como clave principal?

¿Cualquier otra sugerencia?

Answer 1

¿Es una mala idea usar un UUID (String / Varchar) como clave principal en una tabla de base de datos SQL en lugar de un número entero que se incrementaría automáticamente?

El único problema seguro que puedo pensar es que no podrá usar CursorAdapter y sus subclases para mostrar los resultados de las consultas en esa tabla. CursorAdapter requiere una columna _id entera única en el Cursor , y presumiblemente no tendrá una de esas. Tendría que crear su propio adaptador, quizás ampliando BaseAdapter , que lo maneja.

Supongo que habrá problemas de rendimiento mediante el uso de cadenas (un UUID tiene 36 caracteres) como clave principal.

Posiblemente, pero me sorprenderá algo si se convierte en un problema material en bases de datos del tamaño de un dispositivo.

Sin embargo, no puedo ver ninguna otra posibilidad de implementar dicho sistema de sincronización colaborativa, así que debo usar UUID, ¿no?

Necesitas algún tipo de UUID para tu protocolo de red. Presumiblemente, necesitará ese UUID en su base de datos. Si ese UUID necesita ser la clave principal de una tabla, no puedo decirlo, porque no conozco su esquema.

Otra posibilidad sería usar una clave primaria de incremento automático entero y usar una segunda columna uuid. Entonces, para trabajar en el dispositivo local de los usuarios, usaría esta clave primaria (entero) para UNIRSE, etc., mientras que usaría la columna uuid para sincronizar con los otros usuarios.

Correcto. Tendría una tabla UUID-> local integer ID mapping, usaría los UUID en su protocolo de red y mantendría la base de datos local en su mayoría usando los ID enteros locales. No puedo decir si esto será o no una mejora significativa en el rendimiento (especialmente dada la mayor complejidad del esquema de la base de datos).

¿Qué piensan de ese enfoque o, en su opinión, de mucho trabajo, ya que no esperarán un gran problema de rendimiento al usar UUID directamente como clave principal?

En mi humilde opinión, realizo algunas pruebas de rendimiento para obtener datos comparables concretos, o solo me preocupo si la E / S de su base de datos parece lenta.

Answer 2

Se puede encontrar un conjunto de resultados de rendimiento para UUID como binario y texto en una pregunta UUID / SQLite algo relacionada: https://.com/a/11337522/3103448

Según los resultados, los UUID binarios y de cadena pueden ser eficientes en SQLite para Create y Query cuando se indexan. Una desventaja separada es si se prefiere una cadena legible por humanos al tamaño más pequeño de datos del tamaño del archivo binario.