tipos tipo datos dato booleano sql-server database-design replication guid

sql-server - booleano - tipos de datos en sql server 2016



¿Guid es el mejor tipo de datos de identidad para las bases de datos? (8)

Está conectado a BI y a la fusión de datos de diferentes fuentes de datos y haría que el proceso sea más fluido.

¿Y existe una estrategia de migración óptima desde una base de datos sin Guids hasta una versión con Guids sin pérdida de información?

No hay un "mejor" tipo de datos de identidad. Las diversas opciones tienen diferentes fortalezas y debilidades. Yo uso GUID más a menudo que no, pero tengo que tratar regularmente con clientes desconectados y fusionar la replicación, por lo que la elección es adecuada. Si no tiene que lidiar con la replicación (es decir, la situación en la que un usuario agrega nuevos registros mientras está desconectado de la base de datos central), un campo int de incremento automático es la mejor opción.

Tenga en cuenta que GUID (o ''unique_identifier'') para PK es una mala elección, ya que muchas PK tienen un índice agrupado (por lo que todas las filas se almacenan en el disco en el orden indexado). Como los GUID son aleatorios, no es seguro que se anexe una nueva fila al final del índice, pero podría insertarse en el medio del índice. Esto provoca que el disco se descarte ya que las filas deben moverse.

SI considera que GUID, al menos use sqlserver 2005 y versiones posteriores y NEWSEQUENTIALID () para el valor de PK, para obtener GUID secuenciales que son siempre más grandes que el anterior, por lo que siempre se anexan al final del índice. Si no está utilizando sqlserver (pero, por ejemplo, postgresql o está utilizando Oracle y usa CHAR (32) u otro tipo), considere los COMB (consulte: http://www.informit.com/articles/article.aspx? p = 25862 )

Es probable que necesite la instalación para realizar un seguimiento de la fuente con fines de auditoría, especialmente en datos financieros.

Incluso si usa claves sintéticas en su sistema de depósito (que seguramente querrá hacer si tiene varias fuentes de datos), necesitará respaldar la auditoría. Coloque una columna ''Fuente de datos'' y ''Clave natural'' en las tablas de su sistema y rellene con un código para la fuente y una representación de lo que identifica de manera única el registro en la fuente.

Si hace esto, las claves sintéticas solo necesitan números enteros o numéricos lo suficientemente amplios como para almacenar suficientes valores (entradas si <4b filas, los números si son más). Esto significa que serán mucho más legibles que un GUID.

Todo lo que pueda identificar de manera única el registro es un buen tipo de datos de identidad. GUID generalmente es bueno, pero no es la identidad óptima si tiene una identificación única proveniente de los datos de origen. GUID es un valor entero aleatorio que garantiza ser único; sin embargo, en una situación de integración, a menudo desea detectar duplicados de información, no solo hacer coincidir los registros.

Antes no me gustaba el GUID, pero me ha encantado amarlo. Me encanta porque es relativamente uniforme y adoptado, y termino escribiendo menos código usándolo y manteniendo ese código, de lo que normalmente escribiría y mantendría.

Es especialmente útil para el almacenamiento de archivos, donde debe garantizar que un nombre de archivo sea único, en un directorio con una cantidad potencialmente grande de archivos, incluidos archivos preexistentes.

Los GUID son mejores en los escenarios de replicación de datos, con el enfoque de "identidad" que debe tener cuidado para no causar colisiones entre los datos que se replican entre las bases de datos. Espero que esto ayude.

Editado después de leer la respuesta de Frans Bouma, ya que mi respuesta ha sido aceptada y, por lo tanto, se movió a la cima. Gracias, Frans.

Los GUIDs tienen un gran valor único, sin embargo, debido a su naturaleza compleja, no son legibles por los humanos, lo que dificulta el soporte. Si va a usar GUID, es posible que desee considerar realizar algún análisis de rendimiento en las operaciones de datos masivos antes de hacer su elección. Tenga en cuenta que si su clave principal está "agrupada", los GUID no son apropiados.

Esto se debe a que un índice agrupado hace que las filas se reordenan físicamente en la tabla de inserciones / actualizaciones. Como los GUID son aleatorios, cada inserción requeriría que las filas reales de la tabla se muevan para dar paso a la nueva fila.

Personalmente, me gusta tener dos "claves" en mis datos:

1) Clave principal
Valores numéricos únicos con una clave primaria agrupada. Este es el ID interno de mi sistema para cada fila, y se utiliza para identificar de manera única una fila y en claves externas.

La identidad puede causar problemas si está utilizando la replicación de la base de datos (SQL Server agregará una columna "rowguid" automáticamente para las tablas replicadas por fusión) porque la semilla de identidad se mantiene por instancia del servidor, y obtendría duplicados.

2) External Key / External ID / Business ID
A menudo también es preferible tener el concepto adicional de una "identificación externa". A menudo, este es un campo de caracteres con una restricción única (que posiblemente incluya otra columna, por ejemplo, el identificador del cliente).

Este sería el valor utilizado por las interfaces externas y estaría expuesto a los clientes (que no reconocen sus valores internos). Esta "identificación comercial" permite a los clientes consultar sus datos utilizando valores que significan algo para ellos.