Mike P. wrote: > Hello, > > I've decided to use multiple tables for an entity (e.g. "todo_items1," > "todo_items2," "todo_items3," etc.), instead of just one main table > which could end up having a lot of rows (e.g. just "todo_items"). I'm > doing this to try and to avoid a potential future performance drop that > could come with having too many rows in one table.
This sounds to me like the very definition of "Premature Optimization." http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize What you're describing is called "Database Sharding." http://en.wikipedia.org/wiki/Shard_(database_architecture) However, I would very highly recommend the simpler design, unless you are having scaling problems right now. It sounds like you're at the beginning stages of design so I doubt that is the case. Putting optimization before design leads to complex, difficult to maintain systems. At present you have no verifiable metrics to determine whether the more complex design will ever be needed. Why pay the cost for it now? Wouldn't it be smarter to implement optimizations after you have solid metrics to prove the need for said optimizations? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
