bandera 'activa' o no?

Question

OK, así que prácticamente cada aplicación basada en una base de datos tiene que lidiar con registros "no activos". O bien, eliminaciones suaves o marcando algo como "ignorado". Tengo curiosidad sobre si hay pensamientos de alternativas radicales en una columna 'activa' (o una columna de estado).

Por ejemplo, si tuviera una lista de personas

CREATE TABLE people (
    id  INTEGER PRIMARY KEY, 
    name  VARCHAR(100), 
    active BOOLEAN, 
    ... 
); 

Eso significa que para obtener una lista de las personas activas, es necesario utilizar

SELECT * FROM people WHERE active=True; 

¿Alguien sugiere que los registros no activos haría ser trasladado a una mesa separada y donde sea apropiado se hace una UNIÓN para unir los dos?

curiosidad sorprendente ...

EDIT: Quiero dejar en claro, ya voy en este desde una perspectiva purista. Puedo ver cómo el archivo de datos puede ser necesario para grandes cantidades de datos, pero no es de donde vengo. Si lo hace un SELECT * de la gente tendría sentido para mí que esas entradas son en cierto modo "activo"

Gracias

Answer 1

particionar la tabla en la bandera activa, de manera que los registros activos están en una partición, y los registros inactivos están en la otra partición. Luego, crea una vista activa para cada tabla que tiene automáticamente el filtro activo en ella. El motor de consulta de la base de datos restringe automáticamente la consulta a la partición que tiene los registros activos, que es mucho más rápido que usar un índice en ese indicador.

Aquí hay un ejemplo de cómo crear una tabla con particiones en Oracle. Oracle no tiene tipos de columnas booleanas, por lo que he modificado la estructura de su tabla para Oracle.

CREATE TABLE people 
(
    id  NUMBER(10), 
    name  VARCHAR2(100), 
    active NUMBER(1) 
) 
PARTITION BY LIST(active) 
(
    PARTITION active_records VALUES (0) 
    PARTITION inactive_records VALUES (1) 
); 

Si quisiera, podría poner cada partición en diferentes espacios de tablas. También puede dividir sus índices también.

Por cierto, esto parece una repetición de la pregunta this, como novato debo preguntar, ¿cuál es el procedimiento para tratar con duplicados involuntarios?

Editar: a lo solicitado en los comentarios, siempre un ejemplo para la creación de una tabla con particiones en Oracle

Answer 2

Utilizamos banderas activas con bastante frecuencia. Si su base de datos va a ser muy grande, podría ver el valor de migrar valores inactivos a una tabla separada, sin embargo.

Solo necesita una unión de las tablas cuando alguien quiere ver todos los registros, activos o inactivos.

Answer 3

Bueno, para asegurarse de que solo dibuja registros activos en la mayoría de las situaciones, puede crear vistas que solo contengan los registros activos. De esta forma, es mucho más fácil no omitir la parte activa.

Answer 4

La bandera activa es algo fea, pero es simple y funciona bien.

Podría moverlos a otra mesa como sugirió. Sugeriría mirar el porcentaje de registros activos/inactivos. Si tiene más de 20 o 30% de registros inactivos, entonces podría considerar moverlos a otro lugar. De lo contrario, no es un gran problema.

Answer 5

En la mayoría de los casos, un campo binario que indique la eliminación es suficiente. A menudo hay un mecanismo de limpieza que eliminará esos registros eliminados después de un cierto período de tiempo, por lo que es posible que desee iniciar el esquema con una marca de tiempo eliminada.

Answer 6

Pasar a una tabla separada y llevarlas de nuevo lleva tiempo. Dependiendo de la cantidad de registros que se desconectan y la frecuencia con la que deben devolvérselos, podría ser una buena idea o no.

Si la mayoría no vuelve una vez que están enterrados, y solo se usan para resúmenes/informes/lo que sea, entonces reducirá la tabla principal, las consultas serán más simples y probablemente más rápidas.

Answer 7

Sí, lo haríamos. Actualmente tenemos la columna "active = 'T/F'" en muchas de nuestras tablas, principalmente para mostrar la fila 'más reciente'. Cuando se inserta una nueva fila, la fila T anterior se marca F para mantenerla para fines de auditoría.

Ahora, nos movemos a un enfoque de dos tablas, cuando se inserta una nueva fila, la fila anterior se mueve a una tabla de historial. Esto nos da un mejor rendimiento para la mayoría de los casos, mirando los datos actuales.

El costo es un poco más que el método anterior, previamente tenía que actualizar e insertar, ahora tiene que insertar y actualizar (es decir, en lugar de insertar una nueva fila T, modifica la fila existente con todos los datos nuevos) , por lo tanto, el costo es solo el de pasar toda una fila de datos en lugar de pasar solo los cambios. Eso no va a tener ningún efecto.

La ventaja de rendimiento es que el índice de la tabla principal es significativamente más pequeño, y se puede optimizar sus espacios de tabla mejor (no crecerán bastante tanto!)

Answer 8

Utilizamos dos métodos para hacer frente a los registros inactivos. El método que usamos depende de la situación. Para registros que son esencialmente valores de búsqueda, utilizamos el campo de bit Activo. Esto nos permite desactivar entradas para que no se usen, pero también nos permite mantener la integridad de los datos con las relaciones.

Utilizamos el método "mover a tabla de separación" donde los datos ya no son necesarios y los datos no son parte de una relación.

Answer 9

La situación realmente dicta la solución, me parece:

Si la tabla contiene los usuarios, a continuación, varios campos de "bandera" se podrían utilizar. Uno para Suprimido, Deshabilitado, etc. O si el espacio es un problema, entonces bastaría con un indicador de deshabilitado y, en realidad, eliminar la fila si se han eliminado.

También depende de las políticas para almacenar datos. Si hay políticas para mantener los datos archivados, entonces probablemente sea necesaria una tabla separada después de un gran período de tiempo.

Answer 10

No - esto es una cosa bastante común - par de variaciones en función de las necesidades específicas (pero que ya les cubierta):

1) Si usted espera tener un montón de datos - como múltiples terabytes o más - no es una mala idea archivar los registros eliminados inmediatamente - aunque puede utilizar un enfoque combinado de marcado como eliminado y luego copiarlo en tablas de archivo.

2) Por supuesto, la opción de borrar un disco aún existe, aunque los desarrolladores usamos como ratas de paquete de datos. Sugiero que mire el proceso de negocio y decida si ahora hay alguna necesidad de mantener los datos, si los hay, hazlos ... si no los hay, probablemente deberías sentirte libre solo para tirar las cosas ...de nuevo, según el escenario empresarial específico.

Answer 11

Usamos un enum ('ACTIVE', 'INACTIVE', 'DELETED') en la mayoría de las tablas, por lo que en realidad tenemos una bandera de 3 direcciones. Me parece que funciona bien para nosotros en diferentes situaciones. Su experiencia puede ser diferente.

Answer 12

Mover cosas inactivas suele ser una idea estúpida. Es un montón de sobrecarga con mucho potencial para los errores, todo se vuelve más complicado, como desarchivar el material, etc. ¿Qué haces con los datos relacionados? Si mueve todo eso, también, debe modificar cada consulta. Si no lo mueve, ¿qué ventaja esperaba obtener?

Eso lleva al siguiente punto: ¿POR QUÉ lo moverías? Una tabla indexada correctamente requiere una búsqueda adicional cuando el tamaño se duplica. Cualquier mejora en el rendimiento es inevitablemente insignificante. ¿Y por qué piensas en ello hasta el futuro lejano cuando en realidad tienes problemas de rendimiento?

Answer 13

Creo que mirándolo estrictamente como un dato, entonces la forma en que se muestra en la publicación original es correcta. La información de la bandera activa depende directamente de la clave primaria y debe estar en la tabla.

Esa tabla contiene datos de personas, independientemente del estado actual de sus datos.

Answer 14

Desde una "perspectiva purista", el modelo real no diferencia entre una vista y una mesa: ambas son relaciones. De modo que el uso de una vista que usa el discriminador es perfectamente significativo y válido siempre que las entidades sean nombradas correctamente, p. Person/ActivePerson.

Además, desde una "perspectiva purista", la tabla debe llamarse persona, no personas, ya que el nombre de la relación refleja una tupla, no el conjunto completo.

Answer 15

Los indicadores binarios como este en su esquema son una MALA idea. Considere la consulta

SELECT count(*) FROM users WHERE active=1

Parece bastante simple. Pero lo que sucede cuando tienes una gran cantidad de usuarios, tantos que sería necesario agregar un índice a esta tabla. De nuevo, parece sencillo

ALTER TABLE users ADD INDEX index_users_on_active (active)

EXCEPT !! ¡Este índice es inútil porque la cardinalidad en esta columna es exactamente dos! Cualquier optimizador de consultas de base de datos ignorará este índice debido a su baja cardinalidad y hará un escaneo de tabla.

Antes de completar su esquema con indicadores útiles, tenga en cuenta cómo va a acceder a esos datos.

https://stackoverflow.com/questions/108503/mysql-advisable-number-of-rows

Answer 16

En cuanto a la indexación del booleano, por qué no:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ; 

¿Eso no mejora la búsqueda?
Sin embargo, no sé cuánto de esa respuesta depende de la plataforma.