Para almacenar un UUID de 128 bits, hay varias opciones de almacenamiento:
- una columna de byte [16]
- dos columnas bigint / long (64 bits)
- una columna CHAR (36) - 32 dígitos hexadecimales + 4 guiones.
- una columna específica de la base de datos UUID, si db lo admite
Desde el punto de vista de la indexación, ¿cuáles son los más eficientes? Si la base de datos no admite un tipo de uuid dedicado, ¿cuáles de 1, 2, 3 son los mejores candidatos?
sql-server
mysql
oracle
postgresql
index
Vlad Mihalcea
fuente
fuente
raw(16)en Oracle yuuiden PostgreSQL.uuid>>bytea>>textconCHECKrestricción>varchar(36)>>char(36). Ver: dba.stackexchange.com/a/89433/3684 y dba.stackexchange.com/a/115316/3684 .Respuestas:
Un
uuidtipo dedicado es su mejor apuesta para PostgreSQL. Difícil de decir con otros DB: no es imposible que alguien implique unuuidtipo que se almacena de manera menos eficiente que un tipo de byte simple.Nuevamente en PostgreSQL,
byteasería una forma razonable de almacenar UUID si no tuviera eluuidtipo. Para otros DB depende de cómo almacenan los datos binarios.Siempre que sea posible, evitaría utilizar hex-with-guiones. Es mucho menos eficiente comparar, ordenar y almacenar.
Así que realmente, "no (2) o (3)". Nunca. Utilice (4) donde sea compatible, (1) de lo contrario.
fuente
SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]En orden de preferencia: 4,1,2,3 No use UUID como clave de agrupación si usa el servidor SQL, ya que no solo se fragmentará mal, la clave de agrupación se usa en todos los índices no agrupados y agregaría esos bytes a cada fila de índice. La fragmentación se puede mitigar utilizando NEWSEQUENTIALID, pero generalmente prefiere una identidad de bingint para su Clustering Key sobre un GUID para evitar la hinchazón en otros índices.
La diferencia entre elegir 1 sobre 2 dependerá de cuán más eficiente sea la base de datos para manejar dos columnas de tipos básicos sobre una matriz fija de una sola columna. Debería ser lo suficientemente fácil de probar con datos ficticios. Observe la velocidad de sus consultas, así como el tamaño de los índices y los datos. Pequeño + rápido es lo mejor!
fuente
Uno debería suponer que cualquier tipo de datos con soporte nativo estaría mejor optimizado en el producto que cualquier cosa que se pueda reunir como cliente de ese producto. Después de eso, lo que tenga el recuento de bytes más pequeño para que obtenga las filas máximas por página.
fuente