Hola
Tengo una gran tabla de hechos de nivel de transacción con registros de 60M+. Hay alrededor de 15 referencias dimensionales de tipo de búsqueda en el modelo con segmentaciones de datos de referencia simples, como Tipo de venta, Tipo de promoción, etc., cada una de las que se hace referencia mediante una clave externa de identificador entero simple. Esto ha dado lugar a un esquema de estrella con un montón de tablas de "dimensión" de 2 columnas.
¿Qué sería más eficaz para el motor Vertipaq, manteniendo este modelo de búsqueda o perdiendo las claves de búsqueda e integrando el texto del campo de referencia en la tabla de hechos?
es decir, la tabla de hechos iría de
$ Importe,
SaleTypeId,
SaleStatusId,
SalesModeId,
DiscountTypeId,
PurchaseTypeId, [etc]
... cada uno de los que se vincula a la tabla de referencia de 2 columnas, a
$ Importe,
Tipo de Venta,
Estado de venta,
Modo de venta,
Tipo de descuento,
Tipo de compra,
Simplificaría la experiencia de usuario, pero supongo que con 60M+ registros importados, este cambio también afectará al tamaño, la velocidad de búsqueda y la eficiencia de la medida, pero no estoy seguro de cómo el modelo se vería afectado (bueno o malo?) o cuál es la práctica recomendada aquí. ¿Alguien ha visto esto o probado esto antes?
Gracias a todos 🙂
actualizar:
Hice mi propia prueba de concepto y tenía razón. No añade nada al tamaño del modelo para absorber las dimensiones de un solo atributo en la tabla de hechos, abandonando los ids, pk/fk relationsip, abandonando las mini tablas tenues y simplemente cargando el valor de búsqueda directamente en el centro de la estrella.
Modelo de 839 MB en esquema de copo de nieve, registros de 60 m de tabla de hecho
12 de estas dimensiones de búsqueda en el modelo, junto con dimensiones rellenas más tradicionales con múltiples atributos
... los 12 dims de un solo atributo se movieron a valores incrustados en la tabla de hechos
¡El modelo ahora es 843MB, más rápido y más fácil de usar!
Espero que esto ayude a alguien algún día
