I know this isn't directly related to OpenBD, but I'm building an app on it, and I need to make a db design decision. This community is pretty wise about this stuff so I figured I'd ask.
How would you think that busy sites like facebook and myspace manage each users' friends list? With the sites having millions if not hundreds of millions of users, and some users have thousands of friends, one giant table with all friend connections seems like a bad idea. Each user get it's own table? Then you could potentially end up with millions of tables. That doesn't seem like good design either. Granted, a table would only really need to be a few columns. record id (bigINT), member_id(int), friend_id(int), If you had 100million users and on average 100 friends per user, that's 10billion records. But it'd be 10billion small, tiny records with only integer based columns. While that'd be a huge record set, you could probably do a lot with caching, and creating different views. Or, just do a table for each letter of the alphabet? If your last name begins with T, you go int the T table for friends. Then that table only contains the friend records of members who's last name begins with T. That would only require 26 tables, and could then cut 10billion records into tables with only 390million records. DBA's, how would you approach this? -- official tag/function reference: http://openbd.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
