> Yeah that doesn't seem so bad. So instead of having to query a giant > table of everyone's posts, you'd only be querying the <user.id>_stream > tables of all the users you're following. This makes sense in my > hypothetical mind, but the way to implement it I wasn't sure.
Sorry, but it looks like you are trying to solve the problem you do not have yet, and do that by choosing most inappropriate means. A couple of well designed tables will do just fine for a long long long run. Thousands of tables will give you maintenance nightmare pretty soon not to mention the strain this kind of solution would put on OS and file I/O. When (if) the need arises you may want to revise your DB design, maybe introduce de-normalization/partitioning/sharding, maybe take a look on solutions involving memcahced/tokyo tyrrant or similar technologies. Alas, one table per user is not the solution you are looking for. I'd say it is not the solution for ANY problem. This kind of design is a problem itself. So for now I'd suggest to build "the most simple thing that works", then invest some time in learning about database design, factors which limit DB performance, indexing strategies, for starters. And by the way, I believe Twitter problems had nothing to do with rails, it was their message queue system that had problems. Regards, Rimantas -- http://rimantas.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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
