Estoy haciendo una aplicación web en asp.net mvc y estoy eligiendo entre el tipo de datos largo y Guid para mis entidades, pero no No sé cuál es mejor. Algunos dicen que mucho es mucho más rápido. Guid también podría tener algunas ventajas. Cualquiera sabe ?long vs Guid for the Id (Entity), cuáles son los pros y los contras
Cuando GUID pueden ser inadecuados
GUID son casi siempre van a ser más lento, ya que son más grandes. Eso hace que tus índices sean más grandes. Eso hace que tus tablas sean más grandes. Eso significa que si tiene que escanear sus tablas, total o parcialmente, llevará más tiempo y verá un menor rendimiento. Esta es una gran preocupación en los sistemas basados en informes. Por ejemplo, uno nunca usaría un GUID como una clave externa en una tabla de hechos porque su longitud generalmente sería significativa, ya que las tablas de hechos a menudo se escanean parcialmente para generar agregados.
Considere también si es o no adecuado utilizar un "largo". Ese es un número enormemente grande. Solo lo necesita si cree que podría tener más de 2 MIL MILLONES de entradas en su mesa en algún momento. Es raro que los use.
Los GUID también pueden ser difíciles de usar y depurar. Decir "hay un problema con el registro 10034 del cliente, Frank, ve a verlo" es mucho más fácil que decir "hay un problema con {2f1e4fc0-81fd-11da-9156-00036a0f876a} ..." Ints y longs también son más fáciles escribir en consultas cuando lo necesites.
Ah, y no es el caso que nunca obtener el mismo GUID dos veces. Se sabe que ocurre en sistemas muy grandes y desconectados, así que eso es algo a tener en cuenta, aunque no lo diseñaría en la mayoría de las aplicaciones.
Cuando GUID pueden ser apropiados
GUID son el apropiado cuando se trabaja con sistemas desconectados donde se crean entidades y luego sincronizados. Por ejemplo, si alguien hace un registro en su base de datos en un dispositivo móvil y lo sincroniza, o si tiene entidades creadas en diferentes sucursales y sincronizadas a una tienda central por la noche. Ese es el tipo de flexibilidad que te dan.
Los GUID también le permiten asociar entidades sin mantenerlas en la base de datos, en ciertos escenarios de ORM. Linq to SQL (y creo que el EF) no tiene este problema, aunque hay ocasiones en que puede verse obligado a enviar sus cambios a la base de datos para obtener una clave.
Si crea sus GUID en el cliente, es posible que dado que los GUID que crea no son secuenciales, el rendimiento de inserción podría sufrir debido a las divisiones de página en la base de datos.
mi consejo
Un montón de cosas a tener en cuenta aquí. Mi voto es no usarlos a menos que tenga un caso de uso convincente para ellos. Si el rendimiento realmente es su objetivo, mantenga sus tablas pequeñas. Mantenga sus campos pequeños. Mantenga sus índices DB pequeños y selectivos.
esto confirma por qué al cambiar de 'GUID' a largo en tamaño corporativo, la aplicación de administración realmente mejoró el rendimiento en mi caso, gracias por la información. puedo confirmar que es importante para el rendimiento, y también el problema de obtener 'GUID's duplicados que encontré con mi equipo y no conocía la causa en ese momento ... por lo que esto también explica por qué – Niklas
TAMAÑO: Long es 8 bytes GUID es 16 bytes
GUID tiene definitivamentealta probabilidad para ir a ser único y es mejor usar para la identificación de registros individuales en una base de datos (s)
larga (Identidad en DB), podría representar un registro único en una mesa, pero que podría tener registros representados por mismo ID (Identidad), en una o más diferentes tabla como la siguiente:
TableA: PersonID int, name varchar(50)
TableB: ProductID int, name varchar(50)
SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name =''
tanto puede devolver mismo valor, pero en caso de GUID:
TableA: PersonID uniqueidentifier, name varchar(50)
TableB: ProductID uniqueidentifier, name varchar(50)
SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name ='
rara vez se puede tener el mismo valor como identificador obtenido a partir de dos tablas
un vistazo aquí
"GUID definitivamente va a ser único" en realidad no es correcto (aunque para todos los propósitos y propósitos tiene razón) es un algoritmo probabilístico por lo que declaración sería más correcto algo como esto: "GUID es con una alta probabilidad de ser único", pero en realidad no está garantizado (pero el riesgo está cerca del riesgo de ser golpeado por un meteoro) –
@Rune FS: Gracias mate para la corrección, editado en consecuencia –
GUID hará mucho más fácil para crear una entidad 'fresco' en su API, ya que simplemente asigna el valor de Guid.NewGuid(). No se depende de las claves autoincrementadas de una base de datos, por lo que esto desacopla el Modelo de dominio del mecanismo de persistencia subyacente.
En el lado negativo, si utiliza un Guid como índice agrupado en SQL Server, las inserciones se vuelven caras porque las filas nuevas rara vez se agregan al final de la tabla, por lo que el índice debe reconstruirse muy a menudo.
Otro problema es que si realiza selecciones desde una base de datos sin especificar un orden explícito, obtendrá los resultados en un orden esencialmente aleatorio.
Las guías secuenciales evitan el problema del índice agrupado que usted describe. Consulte http://stackoverflow.com/questions/665417/sequential-guid-in-linq-to-sql –
Id va a ser la clave principal, lo que significa que se convertirá automáticamente en un índice agrupado? – Omu
En SQL Server, la clave principal será un índice agrupado de manera predeterminada, pero usted especifica lo contrario. –
Entidades .... en una base de datos? En un mapa hash? –
Las entidades están en mi aplicación, en la base de datos hay tablas donde podría ser bigint o uniqueidentifier – Omu