Diseño de la base de datos Primay Key, ID vs String

Question

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. Un ID int o una cadena única.

Métodos 1:

canciones Tabla: SongID (int), título (cadena), * ** Artista (cadena), Longitud (int) *, ** Album (cadena)

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

SongGenre: *** **** SongID (int), *** Ge NRE **** (cadena)

Método 2

canciones Tabla: SongID (int), título (cadena), * ArtistaID ** (int), longitud (int) *, ** ALBUMID (int)

Género Tabla GenreID (int), nombre (cadena)

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

Clave: Negrita = Clave principal, * El campo ** = clave externa

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

¿Hay alguna razón por la cual esta no sea una buena idea? ¿Hay algo que deba saber?

Answer 1

Está haciendo lo correcto: el campo de identidad debe ser numérico y no basado en cadenas, tanto para ahorrar espacio como por motivos de rendimiento (la coincidencia de claves en cadenas es más lenta que la coincidencia en enteros).

Answer 2

MSSQL puede generar estos identificadores para que cuando se utiliza un int (ver palabra clave IDENTIDAD)

Answer 3

Mi recomendación es: Utilice ID.

Podrá 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.

Answer 4

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

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

Hay casos donde un campo de número de auto no es apropiado o no escala.En estos casos, puede tener sentido utilizar un GUID, que puede ser una cadena en bases de datos que no tienen un tipo de datos nativo para él.

Answer 5

¿Hay alguna razón por la cual esta no sea una buena idea? ¿Hay algo que deba saber?

Sí. Los ID de enteros son muy malos si necesita identificar de forma única los mismos datos fuera de una única 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 hacer crecer esa base de datos, puede ser imposible sin eliminar quirúrgicamente sus datos.

Otra cosa a tener en cuenta es que los ID enteros no son tan flexibles, por lo que no se pueden usar fácilmente en casos excepcionales. Los diseñadores del Protocolo de Internet lo entendieron 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 existe 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 tratar de decidir si tener un paradigma de programación "fuertemente tipado" es mejor que un paradigma de programación "de tipo débil/dinámico". Dependerá de lo que necesites hacer.

Answer 6

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

Citas de: Primary Keys: IDs versus GUIDs

Usando un GUID como un valor de identidad fila se siente más natural-- y ciertamente más verdaderamente unique-- que un entero de 32 bits. El gurú de la base de datos Joe Celko seems to agree. Las claves primarias GUID son una opción natural para muchos escenarios de desarrollo , como la replicación, o cuando necesita generar claves primarias fuera de la base de datos.Pero sigue siendo una pregunta de equilibrar las compensaciones entre los identificadores tradicionales entero de 4 bytes y GUID de 16 bytes:

GUID Pros

• único a través de cada mesa, cada base de datos, todos los servidores
• Permite una fácil combinación de registros de diferentes bases de datos
• Permite la fácil distribución de bases de datos en varios servidores
• Puede generar ID en cualquier lugar, en vez de tener que ida y vuelta a la base de datos
• La mayoría de los escenarios de replicación requieren columnas GUID de todos modos

GUID Contras

• Es la friolera de 4 veces más grande que el tradicional índice de 4 bytes valor; esto puede tener graves implicaciones de rendimiento y de almacenamiento, si usted no tiene cuidado
• engorroso de depuración, donde identificador de usuario = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'
• Los GUID generados deben ser parcialmente secuencial para un mejor rendimiento (por ejemplo, , newsequentialid() en SQL 2005) y para permitir el uso de los índices agrupados