2008/11/28 William Temperley <willtemperley@xxxxxxxxx>
true, if you don't want to search on values too much ,or at all - use float[]. But otherwise, keep stuff in a tables as such.
It might be humongous in size, but at the end of the day - prime thing when designing a db is speed of queries.
Still, I wouldn't go too far down the 'compress and stick in as bytea' road, cos it is quite slippery, even tho might look shiny at first,
you can also consider vertical partition (separate machines). Honestly, I would try different approaches first, on scaled down data set, but focusing on retrieval/update (well, whatever your applications are going to use it for).
Any more normalized and I'd have 216 billion rows! Add an index and
I'd have - well, a far bigger table than 432 million rows each
containing a float array - I think?
Really I'm worried about reducing storage space and network overhead
- therefore a nicely compressed chunk of binary would be perfect for
the 500 values - wouldn't it?
true, if you don't want to search on values too much ,or at all - use float[]. But otherwise, keep stuff in a tables as such.
It might be humongous in size, but at the end of the day - prime thing when designing a db is speed of queries.
Still, I wouldn't go too far down the 'compress and stick in as bytea' road, cos it is quite slippery, even tho might look shiny at first,
you can also consider vertical partition (separate machines). Honestly, I would try different approaches first, on scaled down data set, but focusing on retrieval/update (well, whatever your applications are going to use it for).
--
GJ
