I discovered two possible solutions for applying the database structure for social networks like Facebook.
1.: Developing a 'Relationships' table and placing every friendship in it. For instance: user A adds B as friend (A-B), then your logic puts (A-B) and (B-A) in to the 'Relationships' table. It indexes the very first attribute.
2.: Developing a unique table for the customers that contains buddies. Most databases use nearly 2 billion unique tables, therefore it will not be considered a problem however, the database size is going to be nearly 300 occasions bigger (expecting 300 buddies average per user). Within this scenario, querying buddies wouldn't be an issue (as easy as Choose * FROM)
Any ideas? Shall We Be Held wrong somewhere? Thanks all.
The table-per-user solution that you're explaining sounds essentially like Oracle's partitions feature.
Not quite related, however i recommend this awesome publish: Presentation Summary “High Performance at Massive Scale: Lessons Learned at Facebook”
I believe the relationships table may be the least of the concerns :)
It's not necessary to be worried about maximum table size and things like that. To be able to produce a site like Facebook you need to shard/partition all of your tables to multiple machines anyway.