clave principal SQL, INT o GUID o ...?

Question

¿Hay alguna razón por la que no deba usar un entero como clave principal para mis tablas?

La base de datos es SQL-CE, dos tablas principales de aproximadamente 50,000 entradas por año, y algunas tablas menores. Solo dos conexiones existirán abiertas constantemente a la base de datos. Pero las actualizaciones se desencadenarán a través de múltiples conexiones de socket TCP, por lo que serán muchos subprocesos cruzados que acceden y usan la misma conexión de base de datos. Aunque la actividad es muy baja, las actualizaciones simultáneas son bastante improbables, pero pueden ocurrir un par de veces al día como máximo.

Probablemente usará LINQ2SQL para DAL o conjuntos de datos tipeados.

No estoy seguro si esta información es relevante, pero es por eso que estoy pidiendo, ya que no sé :)

Answer 1

La ventaja de usar GUID primkey es que debe ser único en el mundo, como por ejemplo si mover datos de una base de datos a otra. Entonces sabes que la fila es única.

Pero si estamos hablando de un pequeño db, entonces prefiero entero.

Editar:

Si el uso de SQL Server 2005 ++, puede también utilizar NEWSEQUENTIALID(), esto genera un GUID basado en la fila de arriba.Permite que el problema del índice con newid() ya no esté allí.

Answer 2

Usted debería utilizar un entero - es más pequeño, es decir, menos memoria, menos IO (disco y red), menos trabajo para unirse.

La base de datos debe manejar los problemas de simultaneidad, independientemente del tipo de PK.

Answer 3

¿Hay alguna razón por la que no debería utilizar un entero como clave principal para mis tablas?

No, siempre que cada uno sea único, los números enteros están bien. Las guías suenan como una buena idea al principio, pero en realidad son demasiado grandes. La mayoría de las veces, se usa un mazo para matar una mosca, y el tamaño del Guid lo hace mucho más lento que usar un número entero.

Answer 4

Definitivamente use un número entero, no desea usar un GUID en un índice agrupado (PK) ya que hará que la tabla se fragmente innecesariamente.

Answer 5

No veo ninguna razón para no utilizar un número entero de incremento automático en este escenario. Si alguna vez llega al punto en que un entero no puede manejar el volumen de datos, entonces está hablando de una aplicación escalada hasta el punto de que de todos modos hay mucho más trabajo involucrado.

Tenga en cuenta algunas cosas:

1. Un entero es el tamaño de la palabra nativa para el hardware. Es lo más rápido, sencillo y fácil en la computadora a medida que se obtiene un tipo de datos.
2. Al considerar posiblemente el uso de un GUID, sepa que hacen que las claves primarias sean terribles. Las bases de datos relacionales en general (no puedo hablar para nada, pero MS SQL es un buen ejemplo) no indexan bien los GUID. Hay intrusiones para tratar de crear GUID más amigables con los índices, tómalas o déjalas. Pero, en general, se debe evitar un GUID como PK por motivos de rendimiento.