tool - design your database

Base de datos de diseño de clave Primay, ID vs cadena (6)

¿Hay alguna razón para que esto no sea una buena idea? ¿Hay algo que deba tener en cuenta?

Sí. Las ID de enteros son muy malas si necesita identificar de manera única los mismos datos fuera de una sola base de datos. Por ejemplo, si tiene que copiar los mismos datos en otro sistema de base de datos con datos potencialmente preexistentes o si tiene una base de datos distribuida. Lo más importante a tener en cuenta es que un número entero como 7481 no tiene ningún significado fuera de esa base de datos. Si más adelante necesita aumentar esa base de datos, puede ser imposible sin eliminar quirúrgicamente sus datos.

La otra cosa a tener en cuenta es que los ID de enteros no son tan flexibles, por lo que no se pueden usar fácilmente en casos excepcionales. Los diseñadores del Protocolo de Internet entendieron esto y tomaron precauciones al asignar ciertos bloques de números como "especiales" de una forma u otra (IP de difusión, IP privadas, IP de red). Pero eso solo fue posible porque hay un protocolo que rodea el uso de esos números. Muchas bases de datos no operan dentro de un protocolo tan bien definido.

FWIW, es como intentar decidir si tener un paradigma de programación "fuertemente tipado" es mejor que un paradigma de programación "tipificado débilmente / dinámicamente". Dependerá de lo que tengas que hacer.

Actualmente estoy planeando desarrollar una aplicación de transmisión de música. Y me pregunto qué sería mejor como clave principal en mis tablas en el servidor. Una identificación int o una cadena única.

Métodos 1:

Tabla de canciones: SongID (int), Título (string), * Artist ** (string), Length (int), * Album ** (string)

Género Tabla Género (cadena), Nombre (cadena)

SongGenre: *** SongID **** (int), *** Genre **** (string)

Método 2

Tabla de canciones: SongID (int), Título (string), * ArtistID ** (int), Length (int), * AlbumID ** (int)

Genre Table GenreID (int), Nombre (cadena)

SongGenre: *** SongID **** (int), *** GenreID **** (int)

Clave: Negrita = Clave principal, * Campo ** = Clave externa

Actualmente estoy diseñando utilizando el método 2 ya que creo que acelerará el rendimiento de búsqueda y utilizará menos espacio, ya que un int ocupa mucho menos espacio que una cadena.

¿Hay alguna razón para que esto no sea una buena idea? ¿Hay algo que deba tener en cuenta?

Desde la perspectiva del software, el GUID es mejor como único a nivel mundial.

Citas de: claves principales: ID frente a GUID

El uso de un GUID como valor de identidad de fila se siente más natural (y ciertamente más verdaderamente único) que un entero de 32 bits. El gurú de la base de datos Joe Celko parece estar de acuerdo . Las claves primarias de GUID son un ajuste natural para muchos escenarios de desarrollo, como la replicación, o cuando necesita generar claves primarias fuera de la base de datos. Pero aún se trata de equilibrar las compensaciones entre los ID de enteros de 4 bytes tradicionales y los GUID de 16 bytes:
GUID Pros
Único en cada tabla, en cada base de datos, en cada servidor.
Permite una fácil fusión de registros de diferentes bases de datos
Permite una fácil distribución de las bases de datos en múltiples servidores
Puede generar ID en cualquier lugar, en lugar de tener que ir de ida y vuelta a la base de datos
La mayoría de los escenarios de replicación requieren columnas GUID de todos modos
Contras GUID
Es una friolera 4 veces mayor que el valor de índice tradicional de 4 bytes; Esto puede tener serias implicaciones de rendimiento y almacenamiento si no tienes cuidado.
Incómodo de depurar donde userid = ''{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}''
Los GUID generados deben ser parcialmente secuenciales para un mejor rendimiento (por ejemplo, newsequentialid () en SQL 2005) y para permitir el uso de índices agrupados

Está haciendo lo correcto: el campo de identidad debe ser numérico y no basado en cadenas, tanto por ahorro de espacio como por razones de rendimiento (las claves de coincidencia en las cadenas son más lentas que las de los enteros).

Esto es en gran parte una cuestión de preferencia personal.

Mi opinión y práctica personal es usar siempre las teclas enteras y siempre usar claves sustitutas en lugar de las naturales (así que nunca use nada como el número de la seguridad social o el nombre del género directamente).

Hay casos en los que un campo de número automático no es apropiado o no se escala. En estos casos, puede tener sentido utilizar un GUID, que puede ser una cadena en las bases de datos que no tienen un tipo de datos nativo.

MSSQL puede generar estos ID para usted cuando usa un int (vea la palabra clave IDENTITY)

Mi recomendación es: usar ids.

Podrás cambiar el nombre de ese "Género" con 20000 canciones sin romper nada.

La idea detrás de esto es que la identificación identifica la fila en la tabla. Lo que sea que tenga la fila es algo que no importa en este problema.