En caso de una tabla de base de datos tienen valores por defecto?

Question

Yo estaba teniendo una discusión con un desarrollador en el trabajo sobre el tema de la mesa debe utilizar un valores por defecto. ¿Hay una regla dura y rápida en este o se trata de una zona gris en las mejores prácticas?

Answer 1

Mi regla: si muchos registros que usarán por defecto (al menos inicialmente), entonces me gusta usarlo como un defecto. Por ejemplo, una tabla de imagen de los productos en una tienda en línea puede tener una ruta predeterminada de images/NoPictureYet.png. Con el tiempo, los que se reemplazarán, pero para cargas por lotes de datos en el que simplemente no existen todavía las imágenes (y tal vez la mayoría de ellos nunca lo hará!), Un defecto que tiene sentido (para mí, al menos).

Si no hay ningún defecto sensible (por ejemplo, "nombre" en una base de datos de clientes - no quiero que mi nombre por defecto en "Nombre"), entonces lo hago no anulable y ningún defecto - que es responsabilidad de la aplicación para asegurar que un valor correcto se entró.

Pero no hay reglas duras y rápidas sobre esto. Todo varía un poco;)

Answer 2

Un caso práctico donde Yo he encontrado un buen uso de los valores por defecto es para una columna last_modified.

Esta columna no se actualiza mediante procedimientos almacenados o lógica de negocio, pero se actualiza automáticamente por disparadores cuando cualquier valor en la fila cambia. Sin embargo, también se establece en GETDATE() por defecto para que el valor de una nueva fila contendrá la fecha y hora de cuando fue creado, que es básicamente cuando fue modificada por última vez.

ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
                  DEFAULT GETDATE()
                  FOR last_modified;

La actualización de disparo 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

Answer 3

No hay ninguna regla dura y rápida se puede aplicar. Depende de las columnas. Puede ser totalmente conveniente contar con un tipo de orden por defecto, por ejemplo, pero la idea de un valor predeterminado para un número de teléfono del cliente no tiene sentido.

Answer 4

Yo diría que es una zona gris. Por lo general no me diseñar una nueva base de datos con una gran cantidad de valores por defecto, pero a menudo se necesitan para su uso cuando la mejora de un sistema existente.

Por ejemplo la adición de una nueva columna no nula a una base de datos existente. Es posible que no quiere (o poder) actualizar todo el código que se inserta en esa tabla, por lo que tendría que poner un defecto en él para asegurarse de que ningún código "legado" todavía puede insertar datos (suponiendo que el valor por defecto es apropiada para el código heredado por supuesto).

Answer 5

Los valores por defecto son importantes si la columna debe tener un valor (que no es nulo). De hecho si va a cambiar a partir de una columna que permite valores nulos a no permitir que un valor por defecto es más o menos necesario ya que no todo el código existente puede rellenar un valor. A veces, en este caso el valor por defecto es algo así como 'Unknown'. Esto es especialmente cierto si usted desea utilizar los valores con los de proporcionar los valores por defecto de los registros exisiting donde el campo es nulo en la sentencia ALTER TABLE que cambia la columna NOT NULL

Los valores por defecto son críticos para los campos que la interfaz de usuario normalmente no se ocupa. Por ejemplo tenemos valores predeterminados en columnas date_inserted y user_inserted que el usuario ni siquiera sabe que están allí. Esto es especialmente crítico si muchas aplicaciones diferentes podrían rellenar los datos para asegurar que nadie se olvida de estas columnas.

A continuación, hay columnas que típicamente se les da un valor de entrada de datos que puede cambiar después. Cosas como una columna de estado.

Muchas columnas no pueden realmente tener un defecto sin embargo. Lo que sería la dirección por defecto o nombre de usuario?

Answer 6

tl; dr: Los valores por defecto son la lógica de negocio, y quiero que la lógica de negocio en el modelo de objetos. Como tal, una base de datos no puede contener valores por defecto.

por ejemplo. En la base de datos tengo un campo de bits: IsANicePerson. Este campo se traduce en una propiedad de la clase de persona. Ser optimista por naturaleza, quiero que el valor predeterminado de esta propiedad a ser 'verdadero'. Así que en la clase de persona que implementan este (como el valor por defecto del campo respaldo isANicePerson). Si yo permitir que los valores por defecto en la base de datos tendría que duplicar esta lógica. código duplicado / lógica es malo. De ahí mi objeción a valores por defecto.

exención de responsabilidad:. Vivo en un OO-mundo y usar Linq2Sql

Answer 7

Debe ser bastante simple. Si los datos se deben por lo general ser único para cada fila como el número de teléfono de atención al cliente o el valor por defecto será muy probablemente cambiarán con el tiempo entonces yo no lo usaría. Esto significa que es realmente sólo es útil para el llenado CreateDate, ModifiedDate, u otras columnas de esa naturaleza.

Answer 8

Estas son las pautas que utilizo personalmente con respecto a los valores por defecto que me han servido bien en el pasado. En los siguientes ejemplos, considere un motor de base de datos con múltiples aplicaciones con acceso de lectura / escritura en el back-end. En estos casos, es esencial que la base de datos definen cómo los datos debe ser modelado y por lo tanto garantizar la integridad de los datos.

1) columnas CreatedDate y ModifiedDate. Estas columnas tienen normalmente getdate () (SQL Server) se define como el valor predeterminado. Como se ha mencionado en otras críticas, estos campos se pueden actualizar con disparadores, etc.

2) columnas de estado booleanas. Ejemplos: "IsDefault", "IsDeleted" (para la auditoría), "IsActive", etc. Todos estos campos tendrá generalmente un estado predeterminado lógico que debe ser definido por el modelo de datos. Las excepciones a esta, obviamente, sería campos booleanos de tres estados con valores nulos en 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 por defecto definido. En otras palabras, un valor es requerido por la aplicación.

4) tabla de búsqueda identidades de clave externa: Esta es, probablemente, no es la norma, pero para un montón de claves externas tabla de consulta que definirá un defecto que cubre el estado inicial de un registro. Así, por ejemplo, en una tabla de "eventos" de la columna de clave externa "EventTypeId" (int-autoincrement) tendrá por defecto 1 y representan "General" o algo así. Esto cubrirá la mayoría de los escenarios en los que, por ejemplo, quiero registrar un suceso, pero no se preocupan por un identificador de tipo específico.

5) columnas de cadena no críticos: "Descripción", "Comentario" etc. Por estas columnas generalmente definiré '' como el valor predeterminado puramente a simpify System.DBNull => Null conversión manejo en aplicaciones. Esto es algo que puede no ser aplicable en todos los escenarios especialmente cuando la mesa en cuestión contiene millones de filas y espacio de almacenamiento es un problema.

Así que en resumen, utilice los valores predeterminados para asegurar la integridad de los 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 de interactuar con él se y deben ser obligados a respetar estas reglas. También tenga en cuenta que esta no es la doctrina y que siempre habrá excepciones. Considere cada escenario individual de manera que tenga sentido para su base de datos / aplicación.

Answer 9

Sin duda, un área gris. Es la lógica de negocio clásico de la cantidad de poner en cuestión la base de datos.

Si quisiéramos ser purista y decir que no pertenece lógica de negocio en la base de datos, entonces la respuesta sería no usarlos.

Ser práctico que podemos hacer una excepción ya que a menudo hacemos y permitir que la lógica de un defecto en la base de datos.