Tengo una tabla SQL llamada "EVENTO" y una tabla de copia llamada "PAST_EVENT". La tabla EVENT tiene una clave externa a su PAST_EVENT correspondiente. Dado que:
Decidí tener un duplicado de información en la tabla EVENT en la tabla PAST_EVENT porque mi aplicación está buscando datos sobre eventos actuales y en curso (solo necesita leer de la tabla EVENT), O está buscando eventos que han terminado (solo necesita leer de la tabla PAST_EVENT). Pero nunca ambos. Mi razón es que hacer consultas SQL en un subconjunto de eventos es más rápido que la alternativa .
Alternativa:
¿Qué pasa si, en cambio, consolido ambas tablas en una tabla llamada EVENTO? Luego agregaría un campo booleano indexado en la base de datos, "hasEnded", para consultar eventos en curso o finalizados.
¿Cuál de las estrategias antes mencionadas es más eficaz?
Más información (actualización):
"Ridículo" es la palabra que me viene a la mente. En interés de alguna definición de "eficiencia", desea duplicar los datos y cada modificación a los datos. Eso simplemente no me parece eficiente en absoluto.
Comenzaría con eliminaciones suaves: simplemente una bandera sobre si el evento se elimina o no. Eso hace un buen trabajo al definir los eventos.
Debido a que los dos modos que necesita son todos o solo los que no se eliminan, puede pensar en optimizar el almacenamiento si es necesario. Una opción, si su base de datos los admite, es un índice agrupado en el indicador de eliminación. Por lo general, no se recomienda dicha agrupación en una bandera binaria. Pero si los datos no eliminados son pequeños, puede ser una ventaja para las consultas que buscan eso.
Otra alternativa es utilizar particiones. Algunas bases de datos no le permiten cambiar la clave de partición, lo que representa un desafío.
Finalmente, también podría tener un activador de delete en la tabla de events que cargaría los eventos eliminados en otra tabla. Las consultas sobre todos los eventos requerirían unirlos.