Efficient data storage using MySQL

Question

I'm making a website for my music association, and some PDFs should be visible to the users. Now, there are about 200 users, divided in 10 groups (where one user can be in multiple groups), and 30 instruments. For all musical pieces, the database should know what musical piece in which group belongs to which user and instrument.

For example, when I log in, with my username "Jeroen", the database should know that for "MusicalPiece1" in the group "Group1", I need the pdf for "Instrument1" with "Part1".

Note that on a different musical piece, I might play some other instrument, so "Instrument1" and "Part1" can change. Also note that in "Group1" I might play "Instrument1" "Part1" for "MusicalPiece1", but in "Group2" I might play "Instrument2" "Part2" for that same "MusicalPiece1". At last, it should be possible to change data. (Not too hard, but with a complex data storage it might be very hard...)

So, I need an efficient way to store this data through PHP in a MySQL database, because I don't want to wait minutes before the script calculated what PDFs I should get.

EDIT: The idea is that the input values of the script are:

Username
Group
Musical piece

Now the output (result) should be:

Instrument
Part

This means that every combination gives a specific instrument and part.

Answer 1

This is a database design problem. Here are your entities (tables) and a few columns:

• Member (name)
• Group (name)
• Piece (name)
• Instrument (name)

Since a Member can belong to many Groups, you also need another table, which forms a many:many between these two tables.

• GroupMember

Also, it seems that the instrument is determined by the intersection of the Piece with your Group. Thus, the GroupMember table determines your instrument:

• GroupMember (id_member, id_group, id_piece, id_instrument, id_part)

Thus, for a Piece, you can list a number of GroupMembers, where the instrument is determined. This permits your stipulation that being a Member of more than one Group allows you to play a different Instrument per Group. Note also that the Instrument is set in the GroupMember, which allows different Members of that Group to play different Instruments.

Lastly, I would take the view that a GroupMember has a primary key of (id_member, id_group, id_piece), preventing a Member from joining a Group more than once per Piece (regardless of whether they have the same or a different Instrument, and regardless of which Part they are in).

You should now find that, if these relationships correctly model your scenario, that you can use SQL to discover anything you wish from your data.

---

Addendum, from the comments: sometimes these relational problems are semantic. For example, if we say that a Member cannot be a part of a Group more than once per Piece, then how do we deal with a Member wishing to legitimately play in a Group for the same Piece with two Instruments? The solution there might be to put them into two Groups, each having the same Piece. This seems to be compatible with the third paragraph of your question. Of course, it depends what a "group" actually means in your real-world scenario.

I'd add that your worries about performance are misplaced. You can tune your database with 40K rows into a very fast thing indeed, usually just with the addition of the correct indexes. However, you are optimising too early: get it working first, and then you can research performance issues afterwards. You're on the right track, in my view.