Postres de base de datos: ¿buenas o malas prácticas?

Question

Buscando alguna información sobre si un procedimiento Upsert (insertar o si existe, luego actualizar) se considera una mala práctica en la programación de la base de datos. Trabajo en el servidor SQL si eso tiene alguna relevancia.

En un lugar en el que trabajé hace algunos meses, el gurú residente de DB estableció en estándares de codificación db recién escritos (la mayoría de los cuales estoy de acuerdo), que los Upserts deberían evitarse.

Realmente no puedo ver una razón lógica para esto, y me considero razonablemente consciente de las buenas prácticas de programación. Creo que son útiles para la gestión directa de datos y ayudan a evitar números excesivos de procedimientos almacenados.

Buscando alguna información/discusión que me ayude a llegar a una conclusión al respecto.

Gracias.

Actualización En respuesta a los comentarios:

El contexto específico que me refiero es la creación o actualización de los datos de una representación de entidad de dominio en la base de datos. Digamos, por ejemplo, que existe un objeto "Persona" como representación de la tabla "Persona" en la base de datos. Simplemente necesito un mecanismo para crear una nueva persona o actualizar una existente. Aquí tengo la opción de crear un procedimiento almacenado Upsert, o dos procedimientos almacenados separados: uno para Update y otro para Insert.

¿Alguna ventaja o desventaja en cualquier vista?

Answer 1

El problema principal es sobrescribir un registro existente cuando la intención es agregar un nuevo registro porque lo que se seleccionó como la clave está duplicado. Diga un nombre de usuario, por ejemplo. Verá que el inicio de sesión existe, por lo que debe actualizar cuando debería haber descartado un error de que el inicio de sesión es un duplicado.

Un segundo problema es resucitar un registro eliminado. Digamos que el proceso "A" consulta el registro, el proceso "B" lo elimina y luego el proceso "A" envía un cambio. El registro que se pretendía eliminar ahora está de vuelta en la base de datos en lugar de pasar una excepción a "A" que se eliminó.

Answer 2

Depende de lo que hable. ¿Datos? Bueno, eso está determinado por los procesos de manipulación de datos, o? Si necesito insertar O actualizar, entonces tengo que hacer eso. si se trata de objetos de esquema, similar.

Answer 3

Me gusta programar a propósito.

O bien estoy creando algo, en cuyo caso me gustaría que el inserto falle (duplicar) si ya había una entidad allí. O bien, estoy actualizando algo que sé que está allí, en cuyo caso me gustaría que la actualización falle (lo que en realidad no sucede).

Con upsert/merge esto se pone un poco borroso. ¿Tuve o no tuve éxito? ¿Triunfé parcialmente? Algunos de los valores en la fila son míos (de inserción) y algunos de ellos estaban allí antes?

Habiendo dicho eso, los Upserts son útiles (por eso se implementaron para empezar) y prohibirlos sería simplemente una tontería. Eso es como prohibir las carreteras porque los delincuentes las usan para alejarse de los policías. Hay un número infinito de casos en que los resúmenes son la única manera resonable de hacer las cosas. Y cualquiera que haya trabajado con la sincronización de datos entre sistemas lo sabe.

Answer 4

La objeción en el primer ejemplo de dos procesos, donde un segundo proceso "resucita" un registro eliminado agregando uno nuevo con la misma clave, solo es válido en instancias específicas que resultarían de un diseño deficiente O Sucedería sin importar si un procedimiento de "recuperación" escribió el registro con la clave idéntica o si dos procedimientos separados escribieron el registro insertado.

Cuando se debe evitar una clave idéntica, se utiliza una clave de identidad de incremento automático en la inserción. Cuando no se necesita evitar una clave idéntica, se debe implementar un buen diseño de la base de datos para evitar la creación de "uniones fantasmas". Por ejemplo, en el mundo de las telecomunicaciones, los números de teléfono a menudo se reutilizan y son una clave "única". No pueden ser la clave principal porque la persona # 2 podría "heredar" el número de teléfono pero probablemente no "heredar" la factura impagada o el historial de llamadas vencidas de la persona N. ° 1, etc. Entonces una combinación de una clave principal incremental automática más fechas de servicio u otra se usarían indentificadores únicos en cualquier lógica de combinación para evitar el mal encadenamiento de datos.