Database structure refresher

[phppup]

I'm a bit rusty in the database department and would appreciate a quick review and any pointers.

I'm planning to set up a database for a DJ (that colloquially spins records).

The DJ does work with multiple organizations. Each organization sponsors several events per year. Each event has a separate 'playlist' depending on the audience.

From this skeletal overview, I'm thinking that I should establish a primary key/foreign key relationship (to avoid future complication?).

I'm certain that referencing an auto increment ID as the foreign key associated with the 180 character organization name will save valuable disk space, but how do I reference it when I'm adding a new event that the XYZ org is sponsoring?

Any other refresher pointers appreciated.

[Barand]

11 hours ago, phppup said:

but how do I reference it when I'm adding a new event that the XYZ org is sponsoring?

Your form for entering new events would contain a dropdown listing organisations for the user to choose. The value of each dropdown option would br the organisation's id. This id is posted (with the other event data) for insertion into the event resord.

[gizmola]

Great answer from Barand to your specific question. 

As for your initial question, start with your entities, and the relationships between them.

You mentioned:

• A DJ
• Organizations
• Events
• Playlists

Quote

Each event has a separate 'playlist' depending on the audience.

I'm unclear if this means that an event could have multiple playlists, or just one.

Implied entities are:

• artist
• album
• song/track

So you want to start with the entities and determine which attributes they require.

Every entity will become a table, and every table needs a primary key, which unless you have expertise and a strong reason not to, should be auto incremented unsigned "integer" types.  You want to use the smallest reasonable type.  Some "lookup" tables, you will know in advance will never have more than a handful of rows.  Use a tinyint type.  Use the smallest type you can get away with.  Organizations is a good example here, where you can use a (with mysql for example) a smallint, which unsigned means you could have up to 64k rows in it.  With little chance of ever having anything close to that number of orgs, stay with the 2 byte primary key instead of making everything an integer or worse yet a bigint.

Once you have the entities ready, then relate them together, by determining the type of relationship needed (one to one, one to many, many to many) and at that point add foreign keys and add ables as needed.  There are many ERD design tools that can help with the design process.

[phppup]

@Barand Yes, thanks. That's what I was thinking. And with the drop-down populated with data from a SELECT clause, it will be painless and 100% accurate.

@gizmola Thanks for elaborating. I sometimes wonder how granular I need to be (mostly for database speed, right?) when it comes to these things.

Nonetheless, thanks to my friends at phpfreaks, I've come a long way from my 84 column table that mimicked a spreadsheet.

Although it worked, I imagine the database overlords were cursing my existence. LOL

Edited 22 hours ago by phppup
Clean up post

[phppup]

@gizmola

On 7/23/2025 at 5:21 AM, gizmola said:

I'm unclear if this means that an event could have multiple playlists, or just one.

Septate playlists that could be reused.

The DJ could have one playlist for Rock and Roll audiences, which would be different from the Rap and HipHop list, or the Oldies.

There could be individual songs that appear on multiple playlists, but a single playlist could be defined for a given event based on either the event's or organization's target audience.

Edited 21 hours ago by phppup

[gizmola]

For your first question, make the tables relationally correct to 3rd normal form.   The opposite of normalization is de-normalization, and you have no reason to create anything that is de-normalized.  

So a list is a collection of songs, that can also have associated "categories" or "tags" from the sound of it.  It does seem like you misunderstood the question I posed.  It's understood that lists are entites with 1 -<  Many songs.

The question is the relationship from a list to an event.  Can an event have mulitple playlists?  

If so, then the relationship between an Event and a Playlist is Many >----< Many.  You would probably want a way to order those playlists in the many to many.

I don't know if you understand how to handle a logical many to many relationship between 2 entities, so I'll just tell you the answer:

You create a table that relates to each.  Often people will use the names of the related entites for the table name:

• event
• playlist

So you create a table named event_playlist.

In many cases it is convenient to give that table its own auto_increment key, but you can also just use the combined foreign keys by making the relationship "Dependent".  Dependent relationships become part of that table's primary key.  So one way of doing this is to create this table.

event_playlist
--------------
id  (primary key auto increment)
event_id (fk from id of event table)
playlist_id (fk from id of playlist table)
start_time datetime

 

From the database design standpoint, when you have relationships between tables,  with mysql you need to add "declarative referential integrity" statements that enforce the relationships.  You also need to use (assuming mysql) an engine that supports them, which is typically InnoDB.  

You can define the relationships in the table create statements, but typically it is better to add the constraint separately using "alter table".   Here's examples out of the MySQL manual.

 

 

Database design has to match requirements, and there are many questions you should ask, including what is the purpose of this database, that will have to be maintained, and what are the functions an application needs to have.  Here's one small example:

Can playlists be changed over time, and if they are, how does that effect the use of the playlist within the application?  

If the answer is, that a playlist, once it was part of an event, is meant to be a historic record, then you need to add some sophistication to the database in regards to changes to a playlist.  I'd call this "playlist versioning".   There's no way to know if you need to design in playlist versioning or not, but these are the sorts of questions that need to be answered before you complete design of the database and start coding.