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!
解決方案
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.