J
James Palmer
Guest
I've spent significant time bashing this out for our application recently. The trouble with separating out tables based on their RPB setting is working out what to do when the use of said table inevitably changes. Also it's a lot of hard work setting up all the different areas for all the piddly little tables that are hardly used. In the end, I've got the following structure: Data: Cluster 8, RPB 512 -> For most of the tables Index: Cluster 8, RPB 64 -> For the indexes of the above OrderData: Cluster 8, RPB 512 -> For 8-10 heavily used tables OrderIndexes: Cluster 8, RPB 64 -> For high use indexes Transactions: Cluster 512, RPB 512 -> For a single table that is 60% of the database TransIndex: Cluster 8, RPB 64 -> For the indexes of the above There's probably some little tweaks I'd make to the above if I was doing it again, but overall it's a very simple structure, and it's also very simple for architects to decide where to put new structures. IMO the gains from overcomplicating this aren't sufficient in most cases to make it worthwhile. My 2p.
Continue reading...
Continue reading...