2

I think instead of maintaining a single friendRelations table containing a list of relations of all users on my network it would be better to make a separate Relations table for each user on network, that contains profileIDs of all people & groups the user chooses to follow. This way retreival would be quite faster... any suggestions would be greatly appreciated...!!

Ranhiru Jude Cooray
  • 19,542
  • 20
  • 83
  • 128
Rajat Gupta
  • 25,853
  • 63
  • 179
  • 294
  • 4
    That's actually a terrible idea. Providing adequate indexing and caching where necessary should resolve your performance issues. –  Dec 04 '10 at 04:14
  • consider using a notebook with one user on every page. It takes a longer time to flip through the pages than if you had filled up each line on the page. Sergey is correct multiple tables is a terrible idea. – RC_Cleland Dec 04 '10 at 22:22
  • btw could you elaborate upon why making large no of tables is a bad idea. – Rajat Gupta Dec 06 '10 at 13:03

3 Answers3

5

Remember that databases are generally quite good at indexing (assuming you give them suitable columns to index) so retrieval for a specific user should be fast in any case. Creating a bazillion tables may be slower overall.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
  • I am expecting this network to have large user base like (I would say in million(s)..) and assuming that a single user has avg. 50 friends, the size of table may go above 50 millions rows... Dont you think that I would require some better solution than a single 'Friends' table with 50 million rows, inorder to compute friend list of a user. Would you recommend looking to NoSQL solutions or can MySQL stil handle this problem & subsequent problems like JOINS with 'Posts' table to calculate post for news-feed generation. Thanks so much for your response.. ! – Rajat Gupta Dec 06 '10 at 04:32
  • 1
    The best thing you can do is do some performance testing first. If your database has acceptable performance with a table of that size then you're done. If not, try a different database - some perform better than others with large tables. Be careful with your indexing: indexes are key (if you excuse the pun). If other databases still don't work then you should start looking at other options. – Cameron Skinner Dec 06 '10 at 13:23
0

This seems like a drastic design decision to eliminate a problem that probably won't exist. Knowing very little about how your database is constructed and accessed, it's impossible to say whether this is a bad decision (probably) or if your business requirements are unique and this is the solution (unlikely). My recommendation would be to determine the level of normalization you need, and don't try to eliminate performance issues that don't yet exist.

Should I normalize my DB or not?

Community
  • 1
  • 1
Geo Ego
  • 1,315
  • 7
  • 27
  • 53
  • Thanks so much! I am expecting this network to have large user base like (I would say in million(s)..) and assuming that a single user has avg. 50 friends, the size of table may go above 50 millions rows... Dont you think, I would need some better solution than a single 'Friends' table with 50 million rows, inorder to compute friend list of a user. Would you recommend looking to NoSQL solutions or can MySQL stil handle this problem & subsequent problems like JOINS with 'Posts' table to calculate post for news-feed generation. Thanks so much for your response.. ! – Rajat Gupta Dec 06 '10 at 04:36
-2

If you have performance issues with your database queries for retrieving information I strongly recomend you to use the Vertica database, which is incredibly fast.

mariana soffer
  • 1,853
  • 12
  • 17