It's a common design pattern that you see in relational databases (one-to-many, many-to-many.) Imagine you're writing software which handles a conference like E3 or a technical conference.  Big conferences have little events and meetings happening all over that people can sign up for. 

The first thing you're asked to do is maintain a list of all persons attending.
new table("person") { id:int, name:str, address:str, phone:str, etc }

Next you're asked to maintain a list of all events that will happen.  OK, easy:
new table("event") { id:int, name:str, room:str, date:date, etc }

Now you're asked to create a page which allows you to add persons to events. You could add a new column to person which lists a comma separated list of events that the person is attending.  But what if the event name has a comma in it?  So now you have to write a routine which escapes commas and write a routine which unescapes commas, make sure you test it, etc.  Another downside to this approach is that selecting all persons for a given event will be inefficient as you have to do unescaping and substring matching on the event CSV.  Substring matches are much less efficient than direct equality comparisons.

Instead of starting to use CSV and substring matching, relational database designers came up with design patterns called one-to-many annd many-to-many. To use this, instead of putting the information about an person's events into the persons row, you put information about the person's events in a event_person mapping table.

new table("event_person") { person_id:int, event_id:int }

This is slightly more efficiency than using a CSV and unescape/escape routines to generate a list of events for a given person.

However, the real advantage shows up when you're tasked with generating a list of _persons_ for a given _event_.  If you stored events in a csv in an person column, you would have to iterate over EVERY SINGLE PERSON in the database just to generate a list of attendees for a single event.

But now that you have an event_person mapping table, you can efficiently generate a list of persons for each event by doing something like:

select * from event_person where event_id=X;

This will return the IDs for all the persons of an event without having to iterate over every single person and examining a csv.

Event better, if you get fancier with your SQL, you can skip a second query to the DB to get further information about the persons for an event.  In the above query we only get the person's ID.  Wouldn't it be nice if we could get all the information about the persons for an event, in a single query? You can...

SELECT person.* FROM person INNER JOIN event_person ON person.id=event_person.person_id WHERE event_person.event_id=X;