¿Cuál es el mejor método/opción para los registros vencidos en una base de datos?

Question

En muchas bases de datos en las que parece estar trabajando actualmente, no puedo simplemente eliminar un registro por varias razones, incluso para luego mostrarlas más tarde (digamos un producto que ya no existe) o simplemente guardar una historia de lo que fue.

Así que mi pregunta es cuál es la mejor manera de caducar el registro.

A menudo he añadido una columna date_expired que es el campo de fecha y hora. Generalmente pregunto dónde date_expired = 0 o date_expired = 0 OR date_expired > NOW() dependiendo de si los datos van a caducar en el futuro. Similar a esto, también he agregado una llamada de campo expired_flag. Cuando esto se establece en verdadero/1, el registro se considera caducado. Este es probablemente el método más fácil, aunque debe recordar incluir la cláusula de caducidad siempre que solo desee los artículos actuales.

Otro método que he visto es mover el registro a una tabla de archivo, pero esto puede ser bastante complicado cuando hay una gran cantidad de tablas que requieren tablas de historial. También hace que la recuperación del valor (por ejemplo, país) sea más difícil ya que primero debe hacer una combinación izquierda (por ejemplo) y luego hacer una segunda consulta para encontrar el valor real (o rehacer la consulta con una combinación modificada a la izquierda).

Otra opción, que no he visto ni intenté por completo, es tener una tabla que contenga todos los datos de todos los registros caducados o algún tipo de información, algún tipo de tabla de historial . En este caso, la recuperación sería aún más difícil, ya que necesitaría buscar posiblemente una tabla masiva y luego analizar los datos.

¿Existen otras soluciones o modificaciones que sean mejores?

Estoy usando MySQL (con PHP), así que no sé si otras bases de datos tienen mejores métodos para tratar este problema.

Answer 1

Prefiero el método de fecha de campo caducado. Sin embargo, a veces es útil tener dos fechas, tanto la fecha inicial como la fecha expirada. Porque si los datos pueden caducar, a menudo es útil saber cuándo estuvo activo, y eso significa también saber cuándo comenzó a existir.

Answer 2

Creo que agregar la columna date_expired es el método más fácil y menos invasivo. Siempre que sus INSERTOS y SELECCIONES utilicen listas de columnas explícitas (deberían serlo si no lo son), entonces no hay impacto en sus operaciones existentes de CRUD. Agregue un índice en la columna date_expired y los desarrolladores pueden agregarlo como propiedad a cualquier clase o lógica que dependa de los datos de la tabla existente. En general, el mejor valor para el esfuerzo. Estoy de acuerdo en que los otros métodos (es decir, tablas de archivos) son problemáticos en el mejor de los casos, en comparación.

Answer 3

Por lo general, no me gustan los desencadenantes de base de datos, ya que pueden provocar un extraño comportamiento "entre bastidores", pero poner un desencadenador en eliminar para insertar los datos a eliminar en una tabla de historial podría ser una opción.

En mi experiencia, usualmente solo usamos un bit "Activo", o un datetime "DateExpired" como usted mencionó. Eso funciona bastante bien, y es realmente fácil de tratar y consultar.

Aquí hay una publicación relacionada que ofrece algunas otras opciones. Tal vez la opción CDC?

SQL Server history table - populate through SP or Trigger?

Answer 4

Un enfoque muy agradable por parte de Oracle a este problema es partitions. No creo que MySQL tenga algo similar.

Answer 5

También puedo sugerir agregar una columna "Estado" que coincida con un tipo enumerado en el código que está utilizando. Coloque un índice en la columna y podrá limitar de manera muy fácil y eficiente los datos devueltos a través de sus cláusulas where.

Algunos posibles valores enumerados a utilizar, dependiendo de sus necesidades:

1. activos
2. borrado
3. Suspendido
4. INUSE (Una especie de mecanismo de pseudo-bloqueo)

Establezca la columna como una minúscula (eso es SQL Server ... no estoy seguro del equivalente de MySQL). También puede configurar una tabla de búsqueda coincidente con los pares clave/valor y una restricción de clave externa entre las tablas si lo desea.

Answer 6

Me gusta la opción expired_flag sobre la opción date_expired, si la velocidad de la consulta es importante para usted.

Answer 7

Hay algunos campos que suelen tener mis tablas: creation_date, last_modification, last_modifier (fk to user), is_active (boolean o number, dependiendo de la base de datos).

Answer 8

Siempre he usado el enfoque ValidFrom, ValidTo donde cada tabla tiene estos dos campos adicionales. Si es ValidTo Is Null or > Now(), entonces sabrá que tiene un registro válido. De esta forma, también puede agregar datos a la tabla antes de que esté activa.

Answer 9

Mire los algoritmos SCD de "Dimensión que cambia lentamente". Hay varias opciones del mundo Data Warehousing que se aplican aquí.

Ninguno es "mejor", cada uno responde a diferentes requisitos.

Aquí hay un resumen ordenado.

Tipo 1: El nuevo registro reemplaza el registro original. No hay rastros del antiguo registro existe.

• Tipo 4 es una variante de este mueve la historia a otra mesa.

Tipo 2: Se agrega un nuevo registro en la tabla de dimensiones del cliente. Para distinguir, se requiere un par de columnas de "rango de fechas válidas". Ayuda tener un indicador de "este registro es actual".

Tipo 3: El registro original se ha modificado para reflejar el cambio.

• En este caso, hay columnas para uno o más valores previos de las columnas susceptibles de cambiar. Esto tiene una limitación obvia porque está vinculado a un número específico de columnas. Sin embargo, a menudo se usa junto con otros tipos.

Puede leer más acerca de esto si busca "Dimensión que cambia lentamente".

http://en.wikipedia.org/wiki/Slowly_Changing_Dimension