ID de base de datos predeterminados;valores del sistema y del usuario

Question

Como parte de nuestro trabajo actual con las bases de datos, estamos analizando el proceso de actualización de las bases de datos.

Un punto que se ha planteado recurrentemente es el de abordar el tema sistema vs.valores de usuario;en nuestro proyecto, los valores de usuario y sistema se almacenan juntos.Por ejemplo...

Tenemos una lista de plantillas.

1, <system template>

2, <system template>

3, <system template>

Estos están asignados en la aplicación a una enumeración (1, 2, 3)

Luego entra un usuario y agrega...

4, <user template>

...y...

5, <user template>

Entonces..emitimos una actualización..e insértelo como parte de nuestros scripts de actualización...

<new id> [6], <new system template>

¡¡ENTONCES!!...encontramos un error en la nueva plantilla del sistema y necesitamos actualizarlo...El problema es ¿cómo?No podemos actualizar el registro usando ID6 (ya que es posible que lo hayamos insertado como 9 o 999, por lo que tenemos que identificar el registro usando algún otro mecanismo)

Entonces, hemos llegado a dos posibles soluciones para esto.

En la esquina roja (velocidad)....

Simplemente iniciamos los ID de usuario en 5000 (o algún otro valor) y probamos los datos en 10000 (o algún otro valor).Esto nos permitiría realizar modificaciones en los valores del sistema y probarlos hasta el límite inferior del siguiente rango de ID.

Ventaja... Rápido y fácil de implementar,

Desventaja...¡Podríamos quedarnos sin valores si no elegimos un rango lo suficientemente grande!

En la esquina azul (escalabilidad)...

Almacenamos los datos del sistema y del usuario por separado, utilizamos GUID como identificadores y fusionamos las dos listas mediante una vista.

Ventaja... Escalable... Sin límites con respecto al tamaño de la base de datos.

Desventaja..Más complicado de implementar.(vistas actualizables de muchos a uno, etc.)

---

Me decanto de lleno por la primera opción, ¡pero busco munición que me respalde!

¿Alguien tiene alguna idea sobre estos enfoques, o incluso sobre alguno que hayamos pasado por alto?

Answer 1

Nunca he tenido problemas (rendimiento o desarrollo, TDD y pruebas unitarias incluidas) al usar GUID como ID para mis bases de datos, y he trabajado en algunas bastante importantes.Echar un vistazo aquí, aquí y aquí si desea obtener más información sobre el uso de GUID (y los posibles GOTCHAS involucrados) como claves principales, pero no puedo recomendarlo lo suficiente ya que mover datos de forma segura y sincronizar la base de datos se vuelve tan fácil como cepillarse los dientes por la mañana: -)

Para su pregunta anterior, recomendaría una tercera columna (si es posible) que indique si la plantilla está basada en el usuario o en el sistema, o al menos puede generar GUID para las plantillas del sistema a medida que las inserta y mantiene una lista de aquellos disponibles, de modo que si necesita actualizar la plantilla, pueda apuntar a ese mismo GUID en sus bases de datos DEV, UAT y/o PRODUCCIÓN sin temor a sobrescribir otras plantillas.Sin embargo, la tercera columna sería útil para seleccionar todas las plantillas de sistema o de usuario a voluntad, sin la necesidad de separarlas en dos tablas (esto es excesivo en mi humilde opinión).

Espero que eso ayude,

Rob G.

Answer 2

Recomiendo usar el segundo con la modificación de que almacene los valores del sistema y del usuario en una tabla.GUID es bastante confiable en este sentido.

Otra idea:use cualquier ID basada en texto (no es necesario GUID), que proporcione para los valores del sistema y se genere mediante una cadena aleatoria o una cadena basada en algún tipo de lógica personalizada para los valores del usuario.

Otra idea:utilice el primer enfoque, pero amplíe la tabla con una bandera que muestre si un valor es sistema o usuario.Quizás esto sea lo más fácil.Ok, tienes que escribir algún tipo de mecanismo para actualizar el valor correcto del sistema, pero se puede hacer fácilmente.

Answer 3

+1 para la ID basada en texto de Biri: defina una columna basada en texto "template_mnemonic" y conviértala en la clave principal.Este será un valor conocido cuando lo insertes, ya que los desarrolladores lo habrán decidido (o lo habrán generado automáticamente) y siempre podrás hacer referencia a una plantilla mediante su mnemónico, independientemente de cuántas plantillas especificadas por el usuario haya.También permite a los usuarios tener una convención de nomenclatura significativa para sus plantillas.

Answer 4

Tal vez no lo entendí, pero ¿no podrías usar GUID como identificadores y aún así tener los datos del usuario y del sistema juntos?Luego puede acceder a los datos del sistema mediante los GUID (no modificables).

Answer 5

No creo que el GUID deba causar ningún problema.

Si quieres evitarlo, entonces usa una bandera:

Yo dint

plantilla lo que sea

enumeración de bandera/int/bool

El indicador muestra si el valor real es un valor del sistema o del usuario.

Si desea actualizar un valor del sistema, solicite solo los valores del sistema ordenados por ID y le mostrará el orden de inserción real (debe tener un bigint o algo así para ID para asegurarse de que no se llene y no hace que los ID eliminados vuelvan a funcionar).Con esta lista la x.el registro es la x.valor del sistema insertado.

Answer 6

Creo que hay una tercera solución mejor.Me parece que estás almacenando dos cosas diferentes en la misma tabla y que sería mejor que crearas 2 tablas separadas, una para las plantillas de usuario y otra para las plantillas del sistema.Luego podrá crear una vista sobre las dos tablas para que aparezcan como un único objeto en su aplicación.Obviamente, no tengo un conocimiento completo de su aplicación y esto puede ser imposible para usted por varias razones, pero creo que es una solución mejor que los GUID y mucho más segura que los rangos de ID (en serio, no haga rangos de ID, ya que lo hará). morderte un día)