Jump to content

Database design ala MySpace


nloding

Recommended Posts

I'm sure this has been discussed in the past, but I can't find any old threads.  I can't find much Googling either, just some ColdFusion junk that I wasn't interested in.  Here's the question(s):

If one were designing a social networking site, what is the best approach?

a) Each user gets their own tables (i.e., 1 blog table per user, 1 profile table per user)
b) Every X users, a new table is created (x = 10, so every 10 users is a new table for each blog, profile, etc.)
c) One HUGE table for each category with each user as a row.
d) Some combination of both -- like, one giant table for all profiles, but each user has their own blog table.

I'm in the beginning stages of designing a site that is actually quite complicated.  Here's a brief outline:

Each user has a unique login -- each login is linked to several "characters" -- each character has their own profile like MySpace, Facebook, Friendster, etc -- each profile has friends, blogs, photos, calendars, etc.  At first, this site won't have too many users, but we are expecting up to 10,000.

So ... what do you all think?

You guys are very helpful, thank you in advance for everything!

--Nathan
Link to comment
Share on other sites

Heh, actually not.  It's NOTHING like MySpace or Friendster in it's actual application.  It's a site devoted to a certain clique of people, all of whom share one thing in common.  Picture a MySpace only for Star Wars freaks -- it'd be something like that.  And it's point isn't really "social networking" ...

But regardless, the database design has the same needs at MySpace or Friendster ... hence my question.
Link to comment
Share on other sites

I'm getting heartburn just thinking about the poor server. Literally. Database design rule #82: Never dynamically create tables. Emphasis on never.

The basic idea: create a table user, a table blog, a table profile.

Each time a user is created, add a row to user. Add a row to profile where one of the fields in profile is an ID that matches up with the ID in user. Therefore, the content in profile is linked to the user.

Each time a user makes an entry in their blog, add a row in blog with the information, and link an ID field in blog to the ID field in user.

And that, my friend, is the basic idea.
Link to comment
Share on other sites

Alright, I'll do some digging to foreign keys, which is something I know about but haven't had to utilize yet.

Now, is there an sort of organization that should go into, say, the blog end of it?  Obviously the user can have as many blog entries they want -- and I assume each entry is it own row in the blog table, with the user ID being a key.  Just randomly add the rows down the table as the users enter data?
Link to comment
Share on other sites

[quote author=448191 link=topic=109152.msg439895#msg439895 date=1159007795]
[quote author=neylitalo link=topic=109152.msg439878#msg439878 date=1159004184]
...Database design rule #82:....[/quote]

LOL, is that a random number or from a book?  :P[/quote]

No, I just kinda made it up, no books involved. :)
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.