Al diseñar una tabla, mi colega dice que debería evitar la columna de identidad, ya que es específica de SQL Server y MS Access, pero discrepo con sus puntos de vista ya que simplifica mi codificación.DB: ¿Para utilizar la columna de identidad o no?
¿Debo usar la columna de identidad o no? Si no, ¿cuál es la mejor manera de crear las columnas de identidad desde el código de la aplicación?
No se puede divorciar completamente una aplicación del proveedor de la base de datos. Si lo hace, no podrá aprovechar las funciones que le proporcione su base de datos.
Yo diría que use la columna de identidad. Si te mudas a Oracle (por ejemplo), puedes usar una secuencia. Apenas un gran cambio.
No sé qué tecnología está utilizando, pero una cosa que ayudaría es usar una herramienta como Hibernate o iBATIS (creo que ambas están disponibles para Java y .NET) que lo separa un poco desde los detalles de implementación de la base de datos. Luego, si cambia el proveedor de la base de datos, no necesitará cambiar el código de la aplicación, solo la configuración. (¡En teoría, al menos!)
¿Importa que sea específico de la plataforma de Microsoft? ¿Su aplicación está destinada a ser portátil, es decir, planea migrarla a mysql/postgres/lo que sea?
Hasta donde yo sé, cada RDBMS levemente serio tiene algún tipo de esquema de numeración único por mesa.
Lo uso principalmente, en teoría no siempre es un requisito, pero si desea mantener consulte integridad ential un int es menos para almacenar y más fácil de comparar que un varchar, especialmente si sus claves foráneas serían más complejas que una sola columna.
No está familiarizado con los secuenciadores en Oracle, por lo que decide que "cada RDBMS levemente serio tiene un esquema de números por tabla"? –
@Dave, 42 es siempre un número pero un número no siempre es 42. – Kris
sí, no tengo idea de lo que quieres decir con eso. La última vez que revisé Oracle tenía generadores, al igual que las secuencias de PostgreSQL, que no están en la tabla. –
Usar la columna de identidad!
Separa su "Lógica de aplicación" de "Lógica empresarial".
Digamos que usa "correo electrónico" como clave principal (lo que tiene sentido en términos de "lógica comercial"). Te meterás en problemas cuando ese correo ya no exista y tu usuario quiera editar tu correo electrónico.
No utilice la columna de identidad a menos que sea totalmente consciente de sus peligros y no tenga un motivo válido para usar SEQUENCE o un generador de secuencia emulado.
Las secuencias son mucho más flexibles y no tienen las desventajas/restricciones que tienen las columnas de Identidad.
De http://www.jumpingbean.co.za/blogs/mark/identity_autoincrement_fields_and_database_sequences:
El dolor con incremento automático
copia más datos mientras preservar el valor de identidad
incremento automático teclas puede convertirse en un dolor cuando necesita copiar tablas completas y conservar la clave principal valor. Si intenta insertar directamente en una columna de identidad, se generará un error . Normalmente, el proveedor proporciona algunas declaraciones que le permiten abandonar temporalmente la restricción para que pueda insertar los valores existentes . En MSSQL puede emitir el comando
"SET IDENTITY_INSERT products ON".
Otros proveedores requerirán que elimine la restricción y luego la vuelva a habilitar.
Más dolor: cómo recuperar el valor de filas recién insertadas?
Además el servidor por lo general proporciona diferentes maneras de recuperar el valor de columna de identidad para una fila recién insertada . Para MySQL esta es la función LAST_INSERT_ID() y para MSSQL es @@ identidad, por ejemplo, seleccione @@ identity.
MS SQL Server 2011 admitirá SEQUENCE.
Si utiliza un servidor RDBMS que no admite SECUENCIA (como MSSQL pre-2011 o MySQL), existen dos alternativas:
Creo que si agrega una nueva tabla llamada "IDENTIDAD" y almacena la última ID para cada tabla dentro de ella, sería muy simple decir SET [nombre de tabla] +1 cada vez que necesita una nueva ID para una tabla. – BerggreenDK
No está planeado a partir de ahora, sin embargo, supongo que será el servidor MS SQL para siempre, a menos que MS tenga problemas en el futuro. – Kishork