Estaba teniendo una conversación con un desarrollador en el trabajo sobre el tema de si una tabla usa valores predeterminados. ¿Existe una regla dura y rápida sobre esto o es un área gris en las mejores prácticas?¿Debería una tabla de base de datos tener valores predeterminados?
Mi regla: si muchos registros utilizarán ese valor predeterminado (al menos inicialmente), entonces me gusta usarlo de manera predeterminada. Por ejemplo, una tabla de imágenes para productos en una tienda en línea podría tener una ruta predeterminada de images/NoPictureYet.png. Eventualmente, esos serán reemplazados, pero para lotes de datos donde las imágenes simplemente no existen todavía (y tal vez la mayoría de ellas nunca lo harán), un valor por defecto tiene sentido (para mí, al menos).
Si no hay un valor predeterminado sensato (como "nombre" en una base de datos de clientes, no quiero que mi nombre sea "FirstName"), entonces no puedo aceptar nulos ni valores predeterminados, es la aplicación responsabilidad de asegurar que se ingrese un valor correcto.
Pero no hay reglas duras y rápidas sobre esto. Todo varía un poco;)
Un caso práctico en el que personalmente encontré un buen uso de los valores predeterminados es para una columna last_modified.
Esta columna nunca se actualiza mediante procedimientos almacenados o lógica comercial, pero se actualiza automáticamente mediante activadores cuando cambia cualquier valor de la fila. Sin embargo, también se establece en GETDATE() de forma predeterminada para que el valor de una nueva fila contenga la marca de tiempo de cuando se creó, que básicamente es cuando se modificó por última vez.
ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
DEFAULT GETDATE()
FOR last_modified;
El activador de actualización sería parecido a algo como esto:
CREATE TRIGGER trigUpdate_users
ON users
FOR UPDATE
AS
BEGIN
IF NOT UPDATE(last_modified)
UPDATE users SET last_modified = GETDATE()
WHERE user_id IN (SELECT user_id FROM inserted);
END
GO
hay regla dura y rápida se puede aplicar. Depende de las columnas Puede ser totalmente sensato tener un tipo de orden predeterminado, por ejemplo, pero la idea de un valor predeterminado para un número de teléfono del cliente no tiene sentido.
Debe ser bastante simple. Si los datos generalmente deberían ser únicos para cada fila, como el número de teléfono del cliente o el valor predeterminado probablemente cambiará con el tiempo, entonces no lo usaría. Eso significa que realmente solo es útil para llenar CreateDate, ModifiedDate u otras columnas de esa naturaleza.
Yo diría que es un área gris. Por lo general, no diseñaría una nueva base de datos con muchos valores predeterminados, pero a menudo es necesario usarlos para mejorar un sistema existente.
Por ejemplo, agregar una nueva columna no nula a una base de datos existente. Es posible que no desee (o no pueda) actualizar todo el código que se inserta en esa tabla, por lo que tendrá que establecer un valor predeterminado para asegurarse de que cualquier código "heredado" aún pueda insertar datos (suponiendo que el valor predeterminado sea apropiado). para el código heredado, por supuesto).
Definitivamente una zona gris. Es el clásico de cuánta lógica empresarial incluir en la pregunta de la base de datos.
Si quisiéramos ser puristas y decir que la lógica de negocios no pertenece a la base de datos, entonces la respuesta sería nunca usarlos.
Siendo prácticos, podemos hacer una excepción como solemos hacer y permitir la lógica de un valor predeterminado en la base de datos.
Cómo tonto, integridad de los datos debe ser aplicada a nivel de base de datos o que no tiene integridad de los datos. En el mejor de los casos, es miope para imponer valores predeterminados o restricciones o desencadenar lógica en la aplicación. Esto es más o menos una garantía de datos incorrectos, ya que la base de datos a menudo se ve afectada fuera de la aplicación. – HLGEM
De acuerdo en las restricciones. pero no es un valor predeterminado, no es integridad de datos. – ctrlShiftBryan
Los valores predeterminados son importantes si la columna debe tener un valor (no es nulo). De hecho, si está cambiando una columna para permitir que los nulos no les permitan un valor predeterminado, es bastante necesario, ya que no todos los códigos existentes pueden llenar un valor.A veces, en este caso, el valor predeterminado es algo así como 'DESCONOCIDO'. Esto es especialmente cierto si desea usar los VALORES CON para proporcionar los valores predeterminados a registros existentes donde el campo es nulo en la instrucción ALTER TABLE que cambia la columna a NOT NULL
Los valores predeterminados son críticos para los campos que el usuario la interfaz generalmente no trata. Por ejemplo, tenemos valores predeterminados en las columnas date_inserted y user_inserted que el usuario nunca sabe que existen. Esto es especialmente crítico si muchas aplicaciones diferentes pueden llenar los datos para garantizar que nadie se olvide de estas columnas.
Luego hay columnas que generalmente reciben un valor en la entrada de datos que pueden cambiar más adelante. Cosas como una columna de estado.
Sin embargo, muchas columnas no pueden tener un valor predeterminado. ¿Cuál sería la dirección o el nombre predeterminado de un usuario?
Una distinción que usted hace parece depender de si los datos son realmente "información" o simplemente tareas domésticas. El número de teléfono del usuario es una información sobre la entidad en cuestión (ese usuario en particular). La hora en que se agregó o modificó el registro no es. En cierto sentido, tales cosas no son en absoluto "información", sino más bien una pista de auditoría. Una solución es almacenar toda la información de la limpieza (clave principal interna y externa, tiempo agregado y modificado y por quién, si el registro está marcado como eliminado, etc.) en una tabla separada de los datos reales. Luego puede eliminar los datos y distribuir ese cambio. –
Estas son las pautas que utilizo personalmente con respecto a los valores predeterminados que me han servido bien en el pasado. En los siguientes ejemplos, considere un back-end de base de datos con múltiples aplicaciones con acceso de lectura/escritura al back-end. En estos casos, es esencial que la base de datos defina cómo se modelarán los datos y, por lo tanto, garantizar la integridad de los datos.
1) Columnas CreatedDate y ModifiedDate. Estas columnas generalmente tendrán definido getdate() (servidor sql) como el predeterminado. Como se menciona en otras publicaciones, estos campos se pueden actualizar con activadores, etc.
2) Columnas de estado booleano. Ejemplos: "IsDefault", "IsDeleted" (para auditar), "IsActive", etc. Todos estos campos generalmente tendrán un estado predeterminado lógico que debería ser definido por el modelo de datos. Las excepciones a esto serían obviamente nulables campos booleanos de tres estados donde el estado nulo representa algo acerca de los datos almacenados en el registro.
3) Definiciones de restricciones de datos: Columnas con AllowNull = false y no definidas por defecto. En otras palabras, la aplicación requiere un valor.
4) Identidades de clave externa de la tabla de búsqueda: Probablemente no sea la norma, pero para muchas claves externas de la tabla de búsqueda definiré un valor predeterminado que cubra el estado inicial de un registro. Entonces, por ejemplo, en una tabla de "Evento", la columna de la clave externa "EventTypeId" (int-autoincrement) tendrá el valor predeterminado 1 y representará "General" o algo así. Esto cubrirá la mayoría de los escenarios donde, por ejemplo, quiero registrar un evento pero no me importa un ID de tipo específico.
5) Columnas de cadenas no críticas: "Descripción", "Comentario", etc. Para estas columnas, generalmente definiré "como el valor por defecto simplificar System.DbNull => Tratamiento de conversión nulo en las aplicaciones. Esto es algo que puede no ser aplicable en todos los escenarios, especialmente cuando la tabla en cuestión contiene millones de filas y el espacio de almacenamiento es un problema.
Por lo tanto, en resumen, utilice los valores predeterminados para garantizar la integridad de datos de los datos reales almacenados en la base de datos. El modelo de datos debe definir estas reglas de integridad de datos dentro de sí mismo y cualquier aplicación que interactúe con él deberá y deberá ser obligada a respetar estas reglas. También tenga en cuenta que esto no es doctrina y que siempre habrá excepciones. Considere cada escenario individualmente para que tenga sentido para su base de datos/aplicación.
tl; dr: Los valores predeterminados son lógica de negocios, y quiero lógica de negocios en el modelo de objetos. Como tal, una base de datos no puede contener valores predeterminados.
E.g. En la base de datos tengo un campo de bit: IsANicePerson. Este campo se traduce a una propiedad en la clase Person. Siendo optimista por naturaleza, quiero que el valor predeterminado para esta propiedad sea 'verdadero'.Entonces, en la clase Persona, implemento esto (como el valor predeterminado del campo de respaldo isANicePerson). Si permitiera valores predeterminados en la base de datos, tendría que duplicar esta lógica. El código duplicado/lógica es malo. De ahí mi objeción a los valores predeterminados.
exención de responsabilidad: Vivo en un OO-mundo y usar Linq2Sql.
No es un "defecto" en el verdadero sentido de la palabra. – Andrew
yo preferiría disparadores para '' created_date' y columnas modified_date'. – FrustratedWithFormsDesigner
@ Daniel Vassallo: 'modified_date' tiene que ser hecho como un disparador en la actualización, y me gusta el código de' created_date' para ser coherente con 'modified_date'. ;) Tal vez no sea la MEJOR razón, pero ... ¡bueno! – FrustratedWithFormsDesigner