Ik ben op zoek naar een oplossing voor onderstaande situatie.
Tabel A is een brontabel met daarin klantcontacten. Elk contact dat een klant over een bepaald product heeft gehad staat als een rij opgeslagen in deze tabel. In tabel A staan gegevens tot en met 3 maanden geleden.
Elke week wordt hier een rapportage over gemaakt met daarin:
1) Per product, het aantal unieke klanten.
2) Over het lopende kalenderjaar, per product het aantal unieke klanten
Enkele getallen:
- er zijn ongeveer 300.000 unieke klanten.
- er zijn ongeveer 70 unieke producten.
- Per week komen er 4 miljoen rijen in tabel A bij, en worden er dus ook ongeveer 4 miljoen oude rijen
verwijderd.
- Het aantal unieke combinaties klant, product is per week ongeveer 1 miljoen.
Voor 2) moet ik een oplossing vinden. Het lijkt me dat er in ieder geval een cumulatieve tabel moet komen, laten we deze tabel B noemen, om de historie in op te slaan. In tabel B moet minimaal het customerid en productid worden opgeslagen. Er zijn hier verschillende mogelijkheden:
1) Alle rijen van customerid en productid elke week van tabel A naar tabel B kopieren.
En dan vervolgens elke week op deze tabel het aantal unieke klanten per product queryen.
Nadeel van deze optie is dat aan het eind van het jaar deze tabel uit 200 miljoen rijen bestaat, en het
queryen zal misschien ook niet zo heel snel meer gaan aan het eind van het jaar.
2) elke week alleen de unieke combinaties van customerid en productid erin kopieren, dit gaat vrij snel. Dit scheelt al een factor 4. In tabel B zijn er dan voor een bepaalde week geen dubbele rijen, maar in de gehele tabel B wel.
3) alleen unieke combinaties van customerid en productid in tabel B invoegen. De tabel bevat dan aan het eind van het jaar naar schatting 6 miljoen rijen. Vraag hierbij is of het niet vele malen langer gaat duren om elke week alleen de unieke combos in te laden. Of is hier misschien toch een slimme manier voor?
Welke optie zou jij hier kiezen?
Tabel A is een brontabel met daarin klantcontacten. Elk contact dat een klant over een bepaald product heeft gehad staat als een rij opgeslagen in deze tabel. In tabel A staan gegevens tot en met 3 maanden geleden.
Elke week wordt hier een rapportage over gemaakt met daarin:
1) Per product, het aantal unieke klanten.
2) Over het lopende kalenderjaar, per product het aantal unieke klanten
Enkele getallen:
- er zijn ongeveer 300.000 unieke klanten.
- er zijn ongeveer 70 unieke producten.
- Per week komen er 4 miljoen rijen in tabel A bij, en worden er dus ook ongeveer 4 miljoen oude rijen
verwijderd.
- Het aantal unieke combinaties klant, product is per week ongeveer 1 miljoen.
Voor 2) moet ik een oplossing vinden. Het lijkt me dat er in ieder geval een cumulatieve tabel moet komen, laten we deze tabel B noemen, om de historie in op te slaan. In tabel B moet minimaal het customerid en productid worden opgeslagen. Er zijn hier verschillende mogelijkheden:
1) Alle rijen van customerid en productid elke week van tabel A naar tabel B kopieren.
En dan vervolgens elke week op deze tabel het aantal unieke klanten per product queryen.
Nadeel van deze optie is dat aan het eind van het jaar deze tabel uit 200 miljoen rijen bestaat, en het
queryen zal misschien ook niet zo heel snel meer gaan aan het eind van het jaar.
2) elke week alleen de unieke combinaties van customerid en productid erin kopieren, dit gaat vrij snel. Dit scheelt al een factor 4. In tabel B zijn er dan voor een bepaalde week geen dubbele rijen, maar in de gehele tabel B wel.
3) alleen unieke combinaties van customerid en productid in tabel B invoegen. De tabel bevat dan aan het eind van het jaar naar schatting 6 miljoen rijen. Vraag hierbij is of het niet vele malen langer gaat duren om elke week alleen de unieke combos in te laden. Of is hier misschien toch een slimme manier voor?
Welke optie zou jij hier kiezen?
Before me there was many, after me there will be none. I'm the one!