sql-server - primaria - tipos de indices en sql
GUID como claves principales: OLTP fuera de línea (15)
Estamos trabajando en el diseño de una aplicación que normalmente es OLTP (piense en: sistema de compras). Sin embargo, este en particular tiene la necesidad de que algunos usuarios estén fuera de línea, por lo que deben poder descargar el DB en su máquina, trabajar en él y luego sincronizarlo una vez que están en la LAN.
Me gustaría señalar que sé que esto ya se ha hecho antes, simplemente no tengo experiencia con este modelo en particular.
Una idea en la que pensé fue utilizar GUID como claves de tabla. Entonces, por ejemplo, una orden de compra no tendría un número (auto-numérico) sino un GUID en su lugar, para que cada cliente fuera de línea pueda generarlos, y no tenga conflictos cuando me vuelva a conectar a la base de datos.
¿Es esto una mala idea por alguna razón? ¿El acceso a estas tablas a través de la clave GUID será lento?
¿Has tenido experiencia con este tipo de sistemas? ¿Cómo has resuelto este problema?
¡Gracias!
Daniel
¿El acceso a estas tablas a través de la clave GUID será lento?
Hay otros problemas con los GUID, verá que los GUID no son secuenciales, por lo que los insertos se dispersarán por todas partes, esto provoca divisiones de páginas y fragmentación de índices
En SQL Server 2005 MS introdujo NEWSEQUENTIALID () para solucionar esto, el único problema para usted es que solo puede usar NEWSEQUENTIALID como valor predeterminado en una tabla
¡Comenzaría a mirar SQL Server Compact Edition para esto! Ayuda con todos sus problemas.
Arquitectura de almacenamiento de datos con SQL Server 2005 Compact Edition
Específicamente diseñado para
Aplicaciones de campo (FFA). Los FFA suelen compartir uno o más de los siguientes atributos
Permiten al usuario realizar sus funciones de trabajo mientras está desconectado de la red de respaldo en el sitio en una ubicación del cliente, en la carretera, en un aeropuerto o desde su casa.
Los FFA generalmente están diseñados para la conectividad ocasional, lo que significa que cuando los usuarios ejecutan la aplicación cliente, no necesitan tener una conexión de red de ningún tipo. Los FFA a menudo implican múltiples clientes que pueden acceder y usar simultáneamente datos de la base de datos back-end, tanto en modo conectado como desconectado.
Los FFA deben poder replicar los datos de la base de datos back-end a las bases de datos del cliente para soporte fuera de línea. También necesitan poder replicar los registros de datos modificados, agregados o eliminados del cliente al servidor cuando la aplicación puede conectarse a la red.
@Portman Por defecto PK == Índice agrupado, la creación de una restricción de clave primaria creará automáticamente un índice agrupado, debe especificar no agrupado si no desea agruparlo.
@Simon,
Levantas muy buenos puntos. Ya estaba pensando en los números "temporales" de "lectura humana" que generaría sin conexión, que recrearía en la sincronización. Pero quería evitar hacerlo con claves externas, etc.
@SqlMenace
Hay otros problemas con los GUID, verá que los GUID no son secuenciales, por lo que los insertos se dispersarán por todas partes, esto provoca divisiones de páginas y fragmentación de índices
No es verdad. ¡Clave principal! = Índice agrupado.
Si el índice agrupado es otra columna (surge "inserted_on"), las inserciones serán secuenciales y no se dividirá la página o se producirá una fragmentación excesiva.
Asegúrate de utilizar guid.comb - se ocupa de la indexación. Si tiene problemas de rendimiento después de eso, será, en poco tiempo, un experto en escalar.
Otra razón para usar GUID es habilitar la refactorización de la base de datos. Digamos que decides aplicar polimorfismo o herencia o lo que sea a tu entidad de Clientes. Ahora quiere que los Clientes y Empleados se deriven de Persona y que compartan una mesa. Tener identificadores realmente únicos hace que la migración de datos sea simple. No hay secuencias o campos de identidad enteros para luchar.
El backend será SQL Server 2005
Frontend / Application Logic será .Net
Además de los GUID, ¿puede pensar en otras formas de resolver la "fusión" que ocurre cuando la computadora sin conexión vuelve a sincronizar los datos nuevos en la base de datos central?
Quiero decir, si las claves son INTs, tendré que renumerar todo al importar básicamente. Los GUID me ahorrarán eso.
El uso de GUID nos ahorró mucho trabajo cuando tuvimos que unir dos bases de datos en una.
El uso de Guids como claves principales es aceptable y se considera una práctica bastante estándar por las mismas razones por las que los está considerando. Se pueden usar en exceso, lo que puede hacer que las cosas sean un poco tediosas para depurar y administrar, así que trate de mantenerlas fuera de las tablas de códigos y otros datos de referencia si es posible.
Lo que debe preocuparse es el identificador legible por humanos. Las personas no pueden intercambiar las guías. ¿Se imagina tratando de confirmar su número de pedido por teléfono si se trata de una guía? Por lo tanto, en un escenario sin conexión, es posible que tenga que generar algo , como un id. De editor (estación de trabajo / usuario) y un número de secuencia, por lo que el número de orden puede ser 123-5678 -.
Sin embargo, esto puede no satisfacer los requisitos comerciales de tener un número secuencial. De hecho, los requisitos normativos pueden ser e influir: algunas reglamentaciones (tal vez SOX) exigen que los números de factura sean secuenciales. En tales casos, puede ser necesario generar un tipo de número proforma que se arregla más adelante cuando los sistemas se sincronizan. Puede aterrizar con tablas que tengan OrderId (Guid), OrderNo (int), ProformaOrderNo (varchar): puede aparecer algo de complejidad.
Al menos tener guids como claves principales significa que no tienes que hacer una gran cantidad de actualizaciones en cascada cuando la sincronización ocurra, simplemente debes actualizar el número legible por humanos.
Este es un uso perfectamente bueno de los GUID. El único inconveniente sería una ligera complejidad en el trabajo con GUIDs sobre INT y la ligera diferencia de tamaño (16 bytes vs 4 bytes).
No creo que ninguno de esos sea un gran problema.
Las guías ciertamente serán más lentas (y usarán más memoria) que las claves enteras estándar, pero si eso es o no un problema dependerá del tipo de carga que verá su sistema. Dependiendo de su base de datos DB, puede haber problemas con la indización de los campos guid.
El uso de guids simplifica toda una clase de problemas, pero pagas por el rendimiento y la depuración, ¡las guías de escritura en esas consultas de prueba se volverán realmente rápidas!
Primero pensé en eso: ¿MS no ha diseñado el modelo DataSet y DataAdapter para soportar escenarios como este?
Creo que leí que MS modificó su modelo de conjunto de registros ADO al modelo DataSet actual, por lo que funciona también sin conexión. Y también está este Sync Services para ADO.NET
Creo que he visto un código que utiliza el modelo DataSet, que también utiliza claves externas y aún se sincronizan perfectamente cuando se usa DataAdapter. Aunque no he probado Sync Services, creo que también podría beneficiarse de eso.
Espero que esto ayude.
Si su base de datos es lo suficientemente pequeña como para descargarla en una computadora portátil y trabajar con ella fuera de línea, es probable que no tenga que preocuparse demasiado por las diferencias de rendimiento entre las entradas y las guías. ¡Pero no subestimes lo útiles que son las cosas al desarrollar y solucionar problemas en un sistema! Probablemente tengas que idear una lógica de importación / sincronización bastante compleja, independientemente de si usas Guids o no, por lo que es posible que no ayuden tanto como crees.
Solo voy a señalarte ¿ Cuáles son las mejoras de rendimiento de Sequential Guid en comparación con Guid estándar? , que cubre la conversación GUID.
Para la legibilidad humana, considere la posibilidad de asignar identificadores de máquina y luego usar números secuenciales de esas máquinas como una posibilidad. Sin embargo, esto requerirá gestionar la asignación de ID de máquina. Podría hacerse en una o dos columnas.
Sin embargo, personalmente me gusta mucho la respuesta de SGUID.
Tiene razón en que este es un viejo problema y tiene dos soluciones canónicas:
Use identificadores únicos como la clave principal. Tenga en cuenta que si le preocupa la legibilidad, puede desplegar su propio identificador único en lugar de usar un GUID. Un identificador único usará información sobre la fecha y la máquina para generar un valor único.
Use una clave compuesta de ''Actor'' + identificador. Cada usuario obtiene un ID de actor numérico, y las claves de las filas recién insertadas usan el ID del actor, así como el siguiente identificador disponible. Entonces, si dos actores insertan una nueva fila con ID "100", la restricción de la clave primaria no se violará.
Personalmente, prefiero el primer enfoque, ya que creo que las claves compuestas son realmente tediosas como claves foráneas. Creo que la queja sobre la legibilidad humana es exagerada: ¡los usuarios finales no deberían tener que saber nada sobre las llaves, de todos modos!