Android: utiliza UUID como clave principal en SQLite

Mi aplicación necesita sincronizarse con otros usuarios de la aplicación (en sus propios dispositivos). También quiero apoyar la edición fuera de línea, que se sincronizan con los otros usuarios colaborativos cuando el usuario se conecta a Internet.

Por lo tanto, el usuario A cambia (mientras está fuera de línea) algunos datos (en otras palabras, actualizar las entradas de la base de datos) o agregar 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. El usuario B obtendrá los cambios / actualizaciones y podrá insertarlos / actualizarlos en la base de datos del dispositivo local del usuario Bs.

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

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

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

Supongo que la indexación de uuids en lugar de enteros toma más tiempo (comparación de cadena vs. comparando números enteros). También supongo que cuando Im usando UUID, cada vez que un nuevo registro de base de datos / entrada se ha insertado la base de datos necesita reindexar la columna de clave principal, ya que el índice de clave principal no está en un orden ordenado (que sería cuando yo usaría Entero auto incremento de la clave primaria, ya que cada registro futuro se agrega al final, ya que la nueva clave automática incrementada es siempre el número más grande hasta el momento, por lo que el índice será automáticamente en orden ordenado). Lo que también tengo que hacer es JOINS más de 2 – 3 mesas. También supongo que la comparación de cadenas en JOINS en lugar de entero ralentizaría la consulta de la base de datos.

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

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

¿Qué piensan ustedes acerca de ese enfoque o es en su opinión a mucho trabajo, ya que no esperará un gran problema de rendimiento significativo por ussing UUID directamente como clave principal?

¿Cualquier otra sugerencia?

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

El único problema seguro que puedo pensar es que no podrás usar CursorAdapter y sus subclases para mostrar los resultados de las consultas en esa tabla. CursorAdapter requiere una columna _id número entero único en el Cursor , y presumiblemente no tendrá uno de esos. Tendrías que crear tu propio adaptador, quizás extendiendo BaseAdapter , que lo maneje.

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

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

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

Necesita algún tipo de UUID para su 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 decir, porque no conozco tu esquema.

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

Correcto. Tendrías una tabla de asignación de ID de número entero UUID-> local, usarás los UUID en tu protocolo de red y mantendrás la base de datos local utilizando principalmente los ID de entero locales. Si esto será o no una mejora significativa del funcionamiento (particularmente teniendo en cuenta la complejidad aumentada del esquema de la base de datos), no puedo decir.

¿Qué piensan ustedes acerca de ese enfoque o es en su opinión a mucho trabajo, ya que no esperará un gran problema de rendimiento significativo por ussing UUID directamente como clave principal?

IMHO, ejecute algunas pruebas de rendimiento para obtener algunos datos concretos comparables, o sólo se preocupe si su base de datos de E / S parece lento.

Un conjunto de resultados de rendimiento para UUIDs como binario y texto puede encontrarse en algo relacionado UUID / SQLite pregunta: https://stackoverflow.com/a/11337522/3103448

Según los resultados, los UUID binarios y de cadena pueden ser eficientes en SQLite para crear y consultar cuando se indexan. Un trade-off separado es si se prefiere una cadena legible humana al tamaño de datos más pequeño del tamaño de archivo binario.