Hola Mark
También había estado pensando en estas líneas. Una solución como esta sería genial, y el tiempo no es un problema, pero el estado del cliente tiene que ver con la relación entre los pedidos en un período de tiempo especificado por el usuario, que siempre cambia.
Entonces, los usuarios finales quieren saber durante un cierto período de tiempo cuántos usuarios eran nuevos y qué proporción regresó a nosotros.
Una posible solución sería decir que los usuarios finales solo pueden informar sobre esa información a través de períodos establecidos, como trimestres; entonces, tu sugerencia sería ideal, ya que podría ejecutar ese cálculo en el ETL. Supongo que bajar al nivel mensual haría que todo fuera demasiado engorroso.
Hasta ahora, la tabla derivada ha funcionado bien, solo cuando se filtra por el valor real del pedido las cosas se complican. Como le dije a Durgamadhab Mishra, podría simplemente agregar un aviso de valor de pedido a la tabla derivada y a la tabla de hechos, para que replique mi SQL aquí:
SELECT
CASE WHEN min_prev = 0 AND ords = 1 THEN 0
WHEN min_prev = 0 AND ords > 1 THEN 1
ELSE 2 END AS KS,
uni_usr_id
FROM
(SELECT uni_usr_id, min(prev_orders) min_prev, count(DISTINCT order_id) ords, sum(`netto_eur`) netto_eur
FROM
fact_orders fo
WHERE fo.order_date BETWEEN '2012-01-01' AND '2012-03-31'
AND EXISTS
(SELECT fo2.order_id, sum(netto_eur) net_eur
FROM fact_orders fo2
WHERE fo.order_id = fo2.order_id
GROUP BY fo2.order_id
HAVING net_eur >= 20)
GROUP BY uni_usr_id) a
ORDER BY KS
;
La ventaja de BusinessObjects aquí es que este aviso solo aparece una vez para el usuario.
Saludos
Richard
