¿Es mejor usar un Guid (UniqueIdentifier) como columna principal/clave sustituta, o una columna entera serializada "identidad"? y por qué ¿es mejor? ¿En qué circunstancias elegirías una sobre la otra?¿Cuál es el tipo de ID más común en las bases de datos de SQL Server, y cuál es mejor?
Yo personalmente uso INT IDENTIDAD para la mayoría de mis claves primarias y de agrupamiento.
Debe mantener aparte la clave principal , que es una construcción lógica: identifica de manera única sus filas, tiene que ser única, estable y NO NULA. Un GUID también funciona bien para una clave principal, ya que se garantiza que es único. Un GUID como clave principal es una buena opción si usa la replicación de SQL Server, ya que en ese caso, necesita una columna GUID de identificación única de todos modos.
clustering key en SQL Server es una construcción física que se utiliza para el ordenamiento físico de los datos, y es mucho más difícil de hacer bien. Normalmente, la reina de la indexación en SQL Server, Kimberly Tripp, también requiere una buena clave de agrupación para ser única, estable, lo más estrecha posible e, idealmente, siempre creciente (que es una IDENTIDAD INT).
Ver sus artículos en la indexación aquí:
Un GUID es una muy mala elección para una clave de agrupación, ya que es amplia, totalmente al azar , y por lo tanto conduce a una mala fragmentación del índice y un rendimiento pobre. Además, la (s) fila (s) de clave de clúster también se almacenan en todas y cada una de las entradas de todos y cada uno de los índices no agrupados (adicionales), por lo que realmente desea mantenerlo pequeño: GUID es de 16 bytes frente a INT de 4 bytes y con varios índices no agrupados y varios millones de filas, esto hace una GRAN diferencia.
En SQL Server, su clave principal es por defecto su clave de clúster, pero no tiene que ser así. Puede usar fácilmente un GUID como su clave principal NO AGRUPADA, y una IDENTIDAD INT como su clave de clúster, solo toma un poco de conocimiento.
Tengo que amar a Kim Tripp. –
Entonces, ¿tendría la mesa dos columnas "id" entonces? One Guid y una IDENTIDAD INT? – Nate
@Nate: podría - tener un "ObjectID" de tipo GUID, y un "EntryID" de tipo INT IDENTITY - que funcionaría, sí. –
Muy pocas veces utilizo GUID.
Use más bien una clave principal/clave sustituta para fines de stoage.
También esto facilitará la interacción humana con los datos.
Crear índices será mucho más eficiente también.
Ver
Usar un GUID en un sistema replicado donde tiene que garantizar la unicidad.
Utilice ints donde tenga una base de datos no replicada y desee maximizar el rendimiento.
Use un GUID si cree que alguna vez necesitará usar los datos fuera de la base de datos, es decir, otras bases de datos). Algunos argumentarían, ese es siempre el caso, pero es una decisión de juicio.
Este es un tema frecuentemente debatido, pero tiendo a inclinarme más hacia las identidades por un par de razones. En primer lugar, un entero tiene solo 4 bytes frente a un GUID de 16 bytes. Esto significa índices más estrechos y consultas más eficientes. En segundo lugar, hacemos uso de @@IDENTITY y SCOPE_IDENTITY mucho en procs almacenados, etc. que sale por la ventana con GUIDs.
Aquí hay un pequeño y agradable article by Jeff Atwood.
+++++++ 1 deseo poder haberte podido votar más de una vez :-) –
¡Lo aprecio, Marc! –
No hay una sola respuesta a esto. Los problemas que las personas se apresuran a saltar con Guid (que su naturaleza aleatoria combinada con el comportamiento predeterminado de de la clave principal que también actúa como la clave agrupada) se pueden mitigar fácilmente. Las guías tienen un rango mayor que los enteros, pero a medida que comienzas a llenar ese rango con valores, aumenta el riesgo de una colisión.
Guid's puede ser muy útil cuando tienes un sistema distribuido (por ejemplo, bases de datos replicadas) donde una cantidad no trivial de trabajo tendría que ir a un mecanismo de generación de claves que no causaría colisiones entre las partes del sistema. Del mismo modo, los enteros son útiles porque son fáciles de usar (todos los idiomas tienen un tipo integral, no todos los idiomas tienen un tipo Guid) y pueden ser secuenciales (las guías también pueden, pero no es su uso previsto ).
Todo se trata de lo que está almacenando y cómo. La gente que dice "¡nunca uses Guid's!" solo están difundiendo FUD, pero tampoco son la respuesta a todos los problemas.
Al considerar el uso de enteros, asegúrese de tener en cuenta el valor máximo posible que pueda ocurrir. A menudo termina con números saltados debido a eliminaciones, por lo que la identificación máxima real podría ser mucho mayor que la cantidad total de registros en la tabla.
Por ejemplo, si no está seguro de que un entero de 32 bits funcionará, utilice un entero de 64 bits.
También puede encontrar estos otros SO discusiones útil:
How do you like your primary keys?
What’s the best practice for Primary Keys in tables?
Picking the best primary key + numbering system.
Y si se busca aquí en SO para "clave primaria", podrás encontrar esas y muchas discusiones más útiles.
INT le da 2 mil millones de filas, eso suele ser suficiente :-) –
Creo que es casi siempre un entero de identificación serializado, pero algunos estarán en desacuerdo. Depende de la situación.
Las razones para la identidad son la eficiencia y la simplicidad. Es más pequeño Más fácilmente indexado.Hace gran índice agrupado. Menos fragmentación a medida que se mantienen registros nuevos. Ideal para índices en combinaciones. Más fácil cuando se observan los registros en un db.
Definitivamente hay lugar para Guids en ciertas circunstancias. Al combinar datos dispares, o cuando se deben crear registros en ciertos lugares. Las guías deben estar en su bolsa de trucos, pero generalmente no serán su primera opción.
Hay muchas discusiones existentes sobre este tema, que cubren bastante bien las cosas. –
Sí, ya hay muchas preguntas sobre SO que tratan con esta pregunta exacta. – BBlake
Solo un aparte: Posiblemente necesitamos pensar en mejores formas de buscar en la base de conocimiento SO entonces. Acabo de buscar esto con mucho éxito. Parece que se trata de las diferentes maneras en que puedes expresar la misma pregunta. – Lisa