• Capaz de gestionar grandes volúmenes de información de forma eficiente
• Las consultas pueden actuar simultáneamente sobre datos historificados como no historificados sin penalización en rendimiento

• Si la consulta es compleja (cruza información con otras tablas y/o no se usa el criterio de particionamiento para reducir la volumetría) corremos el riesgo de una explosión en la combinatoria de los resultados, esto lleva a dos consecuencias:
  
  • Alto consumo de memoria en la BBDD
  • Degradación en el funcionamiento del motor de BBDD

• La definición de adecuada de las particiones e indices es fundamental para el correcto desempeño de esta estrategia
• Conviene prestar atención a las consultas que se lanzan sobre esta tabla para que realicen un uso correcto del sistema de particiones y aplicar técnicas de tunning en caso contrario

• OLAP permite almacenar y analizar grandes volúmenes de información de forma rápida y eficiente
• Hay una separación de responsabilidades entre los datos operacionales y los datos históricos

• La consulta simultanea sobre datos operacionales e históricos no es posible  directamente, para hacerlo posible es necesario implementar un orquestador que asuma la responsabilidad de lanzar/adaptar la consulta en cada uno de los sistemas y combinar los resultados.
• Al tener dos sistemas (tres con el orquestador) tenemos otros tantos puntos de error posibles

• Es sencillo de implementar ya que una vez planteado todo se gestiona mediante los dos capos de fecha
• Es acumulable a otras estrategias. Esta técnica es lógica por lo que podemos aplicar otras técnicas en conjunción con ella por ejemplo podemos particionar además por el año de inicio de vigencia que es un dato que existirá en todo caso con lo que sumaremos las ventajas de ambas técnicas 
• Las consultas se lanzan sobre el conjunto total de datos por lo que no hay penalización al consultar datos históricos o mezcla de datos históricos y operacionales

• Por sí misma esta técnica no nos aporta ninguna optimización extra a la de los índices
• Que las consultas realicen un uso adecuado de los índices puede ser algo desafiante especialmente cuando se quieren mezclar datos operacionales y no operacionales (pensemos por ejemplo en una consulta sql sobre una BBDD Relacional donde un " fini<=FECHA and ffin>FECHA" tomará el indice correctamente pero si añadimos los datos operacionales " or (fini<=FECHA and ffin is null)" No hará uso del índice)

• Puede gestionar de forma eficiente grandes volúmenes de información
• La consulta sobre datos historificados y operacionales no tiene penalización alguna dado que cada shard operará en paralelo

• Es necesario algún sistema de BBDD que tenga soporte para esta técnica, por ejemplo: Cassandra, Mysql, Mongo, Elastishearch...
• La indisponibilidad del sistema responsable de la coordinación se shards causa la indisponibilidad de todo el sistema (en el caso de Cassandra el uso de algoritmos de consenso hacen aumentar su resiliencia)
• La indisponibilidad de alguno de los shards hace su información  inaccesible (en el caso de Cassandra el uso de algoritmos de consenso para replica de datos hacen aumentar su resiliencia)

• La información historificada se puede almacenar en un sistema de bajo coste por lo que soportaría una enorme capacidad de almacenamiento

• Son necesarias tres búsquedas: Consulta sobre datos operacionales, consulta sobre los metadatos historificados y búsqueda sobre el almacenamiento con la referencias dadas por los metadatos
• De las tres búsquedas dos (metadatos y almacenamiento) deben ser obligatoriamente secuenciales
• En el mejor de los casos tendremos dos puntos de error, a saber: una BBDD con los datos operacionales y los metadatos y el almacenamiento externo. En el peor de los casos los metadatos estarían en una BBDD independiente por lo que tendríamos tres puntos de fallo: BBDD Operacional, BBDD Metadatos y almacenamiento externo 

El objetivo es mantiene una tabla donde cada cambio implica una nueva tupla reflejando el cambio, en ese sentido se podría considerar como un changelog en BBDD. Al considerar información se auditoria asociada a la tabla podríamos considerar que contiene un historial completo de un dato pero en realidad estos campos serian propios de otras técnicas quedando esta tabla como un changelog y no un estado o una versión de estado

Event sourcing por definición registra cambios/eventos por lo tanto no es aplicable a la historificación de hecho habitualmente podemos ver Event Sourcing para tratar información operativa, tratando esta como un changelog pero al historificar deja paso a alguna de las estrategias ya comentadas (es muy habitual el esquema kafka-Mongo, es decir Event sourcing - Sharding basado en tiempo)