Base de datos: insertar nuevas filas o actualizar las existentes?

Question

El diseño orientado a objetos alienta el uso de objetos inmutables para mejorar la seguridad y el rendimiento del hilo. Me pregunto si esto se traslada a las bases de datos relacionales.

¿Será mejor que actualice las filas existentes o inserte nuevas que actúen como sobrescrituras?

• caso de uso
  • Cada empleado se asocia con exactamente una empresa
  • empleados cambian de empresa en el tiempo.
  • El nombre del empleado debe ser único.
• esquema
  • Empleado [nombre, compañía]

Opción 1: Cada vez que un empleado cambia de compañía, insertar un nuevo [nombre, compañía] fila del empleado. La aplicación recibe instrucciones para omitir las filas más antiguas (que se eliminan en una cadena de fondo a lo largo del tiempo). Opción 2: Cada vez que un empleado cambia de compañía, actualice la fila existente.

La opción 1 me recuerda a los objetos inmutables, ya que es seguro para la ejecución de subprocesos (sin necesidad de bloqueos). Por otro lado, cada vez que el empleado cambia de compañía, tengo que clonar todos los objetos asociados y señalarlos en el nuevo registro. Además, no está claro cómo evitar que los Empleados duplicados se creen por error.

La opción 2 facilita la prevención de empleados duplicados, pero tiene la desventaja de devolver asociaciones potencialmente inconsistentes en el aislamiento de transacciones READ_COMMITTED.

Answer 1

Estoy publicando esto con la esperanza de que esto ayude a otros en el futuro. Personalmente he perdido innumerables días yendo por este camino (equivocado).

Los objetos inmutables son para tipos de valores (piense en enteros, una marca de tiempo, una lectura de temperatura, etc.). Son tipos que nunca cambiarán.En el momento en que comienzas a hablar de modificar los valores de los Objetos Inmutables, es una indicación bastante fuerte de que estás yendo por el camino equivocado. Cuando usa Objetos Inmutables genuinos, nunca debería tener que actualizar las referencias de los objetos asociados.

Así que la respuesta correcta, ya sea para programación orientada a objetos o diseño de bases de datos, es actualizar los objetos mutables en el lugar.

ACTUALIZACIÓN: marc_s menciona el hecho de que algunos sistemas requieren una pista de auditoría inmutables. Sugiero dividir el sistema en dos. La tabla principal actualiza los datos in situ al insertar copias en una tabla de auditoría separada. Esto tiene dos ventajas:

1. La tabla principal puede aprovechar las comprobaciones de integridad (es decir, "los nombres de los empleados deben ser exclusivos").
2. La tabla principal sigue siendo muy rápida para las lecturas y la tabla de auditoría más grande/más lenta se puede recortar con el tiempo.

Esto le permite disfrutar de lo mejor de ambos mundos.

Answer 2

La diferencia básica es la siguiente:

• si inserta una nueva fila para cada cambio, y por ejemplo, "Desactivar" la fila anterior configurando una fecha "ValidTo", luego tiene un historial de los cambios en los que, con el tiempo, ingresa al área de una base de datos "temporal"

• si continúa actualizándose la misma fila una y otra vez, entonces siempre tienes el estado actual, pero no el historial.

así que supongo, esto realmente es la gran pregunta: ¿que hacer necesidad información temporal, por ejemplo, la capacidad de ir "atrás en el tiempo" y ahora ¿cuál era el estado de sus datos hace tres meses? Si es así, la opción 1 (que incluye "eliminaciones suaves", solo marca las filas como eliminadas, en realidad no las elimina) es su única opción. La desventaja es una mayor complejidad y más requisitos de almacenamiento, obviamente.

Answer 3

Esas no son opciones. Son cosas completamente diferentes, y requieren tablas completamente diferentes. La parte dolorosa es que los datos de las tablas pueden parecer exactamente lo mismo. He aquí cómo diferenciarlos.

Cada tabla en una base de datos relacional tiene un único predicado. El predicado determina lo que significan las filas en la tabla. Por lo que una tabla cuyos datos se parece a esto

Name Company 
-- 
Gili Microsoft 
Marc Oracle 

podría significar

Person named "Gili" is currently an employee of company "Microsoft". 
Person named "Marc" is currently an employee of company "Oracle". 

Dicha mesa excluiría a los consultores, porque no son empleados. (En los EE.UU. no lo son, de todos modos.)

pero podría significar

Person named "Gili" once was an employee of company "Microsoft". 
Person named "Marc" once was an employee of company "Oracle". 

y que la mesa también permitirían

Person named "Gili" once was an employee of company "Oracle". 

diferentes predicados, diferentes tablas. (Eso significa que tiene que construir las tablas de manera diferente para captar el significado del predicado.)

Lo que no se puede tener es una tabla que significa

Person named "Gili" is currently an employee of company "Microsoft". 
Person named "Marc" once was an employee of company "Oracle". 

dos predicados diferentes en una misma mesa. No puedo hacerlo en un sistema relacional.

tanto, si su predicado se reduce a esto

Person named NAME is currently an employee of company COMPANY. 

continuación, debe actualizar compañía cuando la persona cambia los empleadores. Y si su predicado se reduce a esto

Person named NAME once was an employee of company COMPANY. 

, entonces debe insertar una nueva fila cuando la persona cambie de empleador.

Answer 4

tblPerson 
    PersonID 
    LastName 
    FirstName 

tblCompany 
    CompanyID 
    CompanyName 

tblCompany_Employee 
    PersonID 
    CompanyID 
    StartDate 
    EndDate 

Filas nunca se eliminan de tblCompany_Employee - Los registros se insertan cuando una persona es contratada, con una fecha de inicio. En el momento en que finaliza el empleo, EndDate se ACTUALIZA de NULL a la fecha en que terminaron los poderes.

Para buscar empleados actuales para una empresa en particular, SELECCIONE PersonID FROM tblCompanyEmployee WHERE EndDAte IS Null.

para ver el estado del empleo para una persona en particular en una compañía específica:

SELECT PersonID 
FROM tblCompany_Employee 
WHERE PersonID = @PersonID 
AND CompanyID = @CompanyID 
AND EndDate IS Null 

NOTA: Lo anterior probablemente debería ser envuelto en una función que sólo devuelve verdadero de un EmployeeID válido se devuelve - Si la persona Nunca se empleó en la empresa en cuestión la declaración no devolvería registros, por lo tanto falsa.

En este caso, una pista de auditoría se mantiene, y es posible (con un poco de refinamiento additiona, obviamente - He puesto este bonito crudamente aquí) para determinar:

A. La Historia de empleo para una persona en todas las empresas B. todas las personas que han sido empleados por una empresa en particular C que se encuentra actualmente empleado por una determinada empresa D. que no es empleado actualmente por una determinada empresa D. Etc.

Sin perder nunca datos debido a ACTUALIZACIONES que sobrescriben el registro histórico.

Answer 5

En general, Data Warehousing tiende a seguir el patrón de "solo insertar". La razón es que todavía se necesitan filas obsoletas en las tablas de domension para ubicar los hechos antiguos en el contexto que existía cuando eran hechos nuevos.

Ejemplo: Pennsylvania fue parte de la región de ventas del noreste hasta el 1 de enero, cuando pasó a formar parte de la región de ventas del Atlántico Medio. Una venta que se realizó en diciembre pasado debe referirse a una fila en la tabla de dimensiones geográficas que lo ubica en la región noreste. Una actualización en lugar de la tabla de dimensiones del "Estado" invalidaría este hecho anterior.

La tendencia en las bases de datos OLTP es realizar actualizaciones en su lugar, y solo hacer un seguimiento de lo que actualmente es el caso. Sin embargo, esto puede provocar la copia de algunos datos en filas de transacciones. Por ejemplo, la fila de detalles de la factura en un sistema de orden de compra puede contener el precio del artículo ordenado, copiado de la fila en la tabla de productos. De esta forma, si el precio se actualiza en la tabla de productos, el precio que afecta a esta factura no se deteriora.