¿"Castigar" a los desarrolladores o arreglarlo automáticamente? Disparador vs restricción

Question

Digamos que tengo una columna de base de datos que siempre debe estar en mayúscula.

Aquí hay un par de ideas:

1) Cree una restricción de columna de: col = UPPER (col)

2) Cree un activador de fila de inserción / actualización anterior que establezca: col = UPPER (col)

Por lo general, mientras más restricciones haya en los datos de su base de datos, mejor, y los desencadenantes pueden ser misteriosos y malos. Supongamos que los desarrolladores que escriben el código están en la misma organización y que el código que escriben puede ser modificado por nosotros.

¿Qué enfoque usarías y por qué?

Tiene que estar en mayúsculas porque los datos en cuestión siempre están en mayúsculas (originalmente fueron impresos de esa manera por varios terceros). No hay significado en mayúsculas o minúsculas para este campo en particular.

Answer 1

Depende de por qué la columna debe estar en mayúscula, pero en general iría por la restricción.

No me gustan las cosas que cambian mis datos cuando los inserto en la base de datos. Significa que tengo una discrepancia entre lo que escribí y lo que leeré la próxima vez.

Si un usuario ha ingresado el texto, considere agregar una columna adicional que contenga la versión en mayúsculas. De esta manera, siempre muestra el texto de la forma en que el usuario lo ingresó

Answer 2

En la mayoría de las situaciones, diría (1), porque como usted señaló, los desencadenantes a menudo pueden ser malos / extraños (aunque no siempre). Pero cuando trato con la sensibilidad de mayúsculas y minúsculas, tiendo a tratar eso como un caso especial y siempre lo arreglo en cada paso del camino. No estoy seguro de tener razones concretas para hacerlo, simplemente " siente " Correcto. Probablemente porque en la mayoría de los entornos en los que he trabajado, desde el punto de vista de la lógica empresarial FoO siempre es igual a foo siempre es igual a FOO .

Además, en este caso, parece que el desarrollador tiene menos carga para decir "FYI", todas las cadenas se almacenan en mayúsculas en el servidor " que golpear su muñeca cada vez que se olvidan. No es como decir "FYI, cada vez que inserte un precio en la base de datos, se agregará el impuesto sobre las ventas".

Answer 3

Esto se implementa mejor como una restricción, evita la carga adicional y hace lo que desea: forzar que los datos estén en el formato que necesita.

Creo que es un enfoque incorrecto para forzar la conversión en la base de datos porque los datos que pueden convertirse sin pérdida de integridad deben manejarse en la capa de la base de datos. Si el caso es insignificante, manéjelo como tal, y una restricción ayuda a detectar errores.

Agregar un índice insensible a mayúsculas y minúsculas puede ser una mejor solución (cf. Índice insensible a mayúsculas y minúsculas de la base de datos )

Answer 4

O aumente la cobertura de las pruebas automatizadas y evite la carga adicional en el servidor de producción.

Answer 5

Consideraría otro enfoque también: proporcionar una "Tabla API" eso permite a los desarrolladores simplemente pasar valores a un procedimiento almacenado (o lo que sea) que luego asegura que los valores estén en mayúsculas en la inserción (según su ejemplo). También respaldaría esto con una restricción (puede ayudar a la optimización de consultas para una cosa) y eliminaría los privilegios de cambio directo en la tabla: si no confía en los desarrolladores para poner en mayúsculas todas las inserciones, entonces no debería confiar en ellos para siempre use el TAPI tampoco.

Answer 6

SI puede hacer algo en una restricción de columna en la base de datos y viceversa, generalmente se prefiere, ya que a menudo es más rápido. Si está hablando de hacer cumplir la aplicación, no lo recomiendo. Si la regla siempre debe aplicarse, nunca debe estar en ningún lugar excepto en la base de datos. Cualquier otra cosa que no sea la aplicación para la que está escribiendo código puede cambiar los datos en una base de datos. La integridad de los datos es responsabilidad de la base de datos, mantenga el código donde pertenece para evitar problemas.