You should never put multiple units of information in a single "cell" of a database table; instead, model your information carefully and then construct your tables to support the data model.
What you're describing is this:
| dev | ---------<| proj |
This entity-relationship diagram shows a one-to-many relationship between developers and projects. In other words, one developer may be responsible for several projects.
Converting this to tables is straightforward.
Your developer table should have a unique ID for each developer.
Your projects table should have a column for a developer's ID. Inserting an ID (from the developer table) into that column (of the projects table) establishes the one-to-many relationship.
The pseudocode to display the results of this operation would look something like this:
select from the developer table
for each developer
print his/her personal info
select from projects where the id matches the developer's id
for each matching project
print the interesting project info
end
end
All of this assumes a one-to-many relationship.
If the relationship is many-to-many (each developer can have multiple projects; each project can have multiple developers), your data model is different, as are the table implications.
The entity-relationship model looks the same at first glance, but notice that there are crow's feet at BOTH ends of the line:
| dev | >---------< | proj |
This little change implies a big change in the tables that implement the model -- you're going to need a third table to express the many-to-many relationship.
You'll need the developer table, as before. You'll need the projects table, but it won't need a column for a developer ID. It will need a column for a unique project ID.
The third table is a relational table -- you might call it DEVELOPERS_TO_PROJECTS.
It really only needs two columns: one to contain developer IDs, the other to contain project IDs. Neither of these columns contains unique data, unlike the similar columns in the other two tables.
To establish a relationship, you retrieve a developer's ID from the developer table, retrieve a project's ID from the projects table, and insert a new row in the relational table, each value going into the appropriate columns.
To sever a relationship, you delete the row where the id's match the developer and the project.
To display all of this, your pseudocode would work like so:
select from the developer table
for each developer
print his/her personal info
select project_id from DEVELOPERS_TO_PROJECTS where the id matches the developer's id
for each matching project
select from projects where the project IDs match (this is different from the previous example, where we were looking for a developer ID in the project table)
for each project retrieved,
print the interesting project info
end
end
end
