3 ms·

Okay. So its a matter of optimising for speed. Since my work requires flexibilty we just try to approximate normalization (I'm not strong on 1St, 2nd etc) - I g

Okay. So its a matter of optimising for speed. Since my work requires flexibilty we just try to approximate normalization (I'm not strong on 1St, 2nd etc) - I guess what you describe a t2. Even with milions of rows its normally pretty fast to aggregate rows for e.g. one customer. Depending on the complexity. It might.take a few seconds.to.filter by delivery.method, group by payment etc... But any ways... it seems to me, one would allways design for flexibilty (t2). And then just create views for the special cases you describe?

DenisM 6y ago
>it seems to me, one would always design for flexibilty (t2) Clearly not - the OLAP field exists and brings in untold billions of dollars, so there is no shortage of takers. OLAP design is about finding an optimal point between two extremes: 1. put effort to pre-compute everything, gain a lot of speed while looking at the result. 2. don't pre-compute anything, spend more time waiting to visualize the result. If things are fast enough for you in the extreme #2 then you don't need to precompute everything and you can enjoy the flexibility. But for many people this is not the case - they either want results in split-second (highly interactive systems, modeling with varying parameters over an over again), or they want to dramatically increase amount of data (e.g. not just all sales but also all page views).
- stilisstuk 6y ago
  Yes off course. It humbles me. I thought i've dealt with pretty big data, but with no need to be speedy, clearly. Thx