mysql query normal relationship table vs concatenated realtionship table

Question

I have a question about relationships between two tables.

Let's say we have a table users, and links.

users
+++++++++
id name
1  name1
2  name2
3  name3
+++++++++

---

links
+++++++++
id link
1  link1
2  link1
3  link1
+++++++++

Now the normal way to link these two is with a name_links table. For example:

name_links
++++++++++++
uid  lid
1    1
1    3
2    3
2    1
2    2
3    2
++++++++++++

Now i was wondering if it is a good idea to make a table like this

name_links
++++++++++++
uid  lid
1    1,3
2    1,2,3
3    2
++++++++++++

Pros and cons i can think of are:

pros1:

You will always search on indexes, faster queries example select where uid=1 and then select links 1,3. Both are indexes so it will be a fast load.

If you have 1000 users, and they each have 20 links, this means you have to go trough 20.000 records to get all the links(i think, not sure of this). Using this method you only take one index and you are done.

cons1:

You will have to update the name_links table more frequently, read, edit, and write example user 2 deletes link2 the method will be:
+ get the string of user 1
+ remove the number from the string
+ insert the new string

Everything here is done on an index, so i assume it will be fast.

cons2:

Another con is when you delete link 2, you have to go trough all the strings, but lets say this is not as much of a problem, as this will not happen often.

This is what i can come up with so far, and I am at the point of my project where i have to decide with which to go.

I would love to have some advice on which method to choose. Do i have my pros and cons right? Are there things I am not taking in considering. Any help on this topic will be highly appreciated.

Thank you guys!

Answer 1

You absolutely should NOT concatenate records unless you absolutely have to. Consider future abilities, lets say you want to count how many users have link 3, that's a pain with your second method.

So I assume by your example this will be a many-to-many join, meaning a link could be connected to many users and many users can be connected with a link. So you potentially have attributes that have to do with a users connecting to a link, like time_linked That could go on your name_links table.

Answer 2

I'm by no means a database expert, but your second option strikes me as a very bad idea. Even assumming you'll never need to, say, do a search by link in the name_link table, doing anything with the links will be a lot of (unnecessary, IMO) extra work.

Answer 3

Denormalized solution has these drawbacks:

• You cannot efficiently join the names and the links (FIND_IN_SET is not sargable)

• You cannot enforce referential integrity using FOREIGN KEYs (in InnoDB)

• Deleting and adding a name-link relationship is more complex

If you never search for names given a link and the links are few in number, you may possibly benefit by getting rid of an extra join.

You should make sure that the performance benefit is real, you really need it and you are aware of the complications of maintaining a denormalized table.

If the links are fixed, you can consider using a native SET datatype instead.