I'm implementing a 'buddy list' -IM messenger application for a website...its just like any usual buddy list you see ie aim, yahoo, msn... the maximum number of buddies one can add to their buddy list is 500 and so far, my implementation for the buddy list table looks like this: userID | friendID_1 | friendID_2 | friendID_3 ..... | friendID_500 --------------------------------------------------------------------- 1 5 9 13 200 Code (markup): So each row contains 501 columns, 500 slots opened for buddies and 1 for the user's ID (the friendID_i column remains empty and gets filled up as the user adds buddies to their buddy list) I realize that 500 columns per row is probably going to look really ugly and slow down performance by a lot... Whats a better way to go about implementing this? I just want to be able to keep track of which buddy belongs to which user.
hi, better would be userID | friendID 1 5 1 9 1 13 etc... 997 1 997 5 997 983 Code (markup): put an index on userID (for speed) and in the language you are writing in do a 'select friendID from buddy where userID=?' to get the friends of a user. This way you can have endless number of friends for a user. Try following a tutorial on internet about mysql and your favorite language (for example for php: http://www.tizag.com/mysqlTutorial/ ) Hope this helps, with kind regards, Dan
What Dan3 did is called 'normalizing'. Do a google search for it and learn about it. It's very important if you want to create databases that are easy to maintain and to query.
I PM'd child a possible solution, which includes a relationship table. The user recid, buddy recid, and relationship typerecid would be persisted in table. I offered another option for storing state. I hope it helped! Good luck, SN
@Dan, if I do not understand the exact requirements I will PM the owner of the thread for clarification. Sometimes, I offer high-level solutions based on my understanding of the problem in the PM too. I had to update a response to another post, because I misunderstood the post ... I felt stupid of course thus the PM strategy. I am still a newbie and learning protocol, sorry.
Not understanding (or wrongly interpreting) the info a poster gives, is something that happens often. It isn't easy to give all info needed in a post, and it isn't always easy to interpret a post. So no need to feel stupid, if your answer isn't what the OP needed. Your solution might still be useful to someone else. And posting your contribution instead of PM-ing it, will save other posters time if you already solved the problem.