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 and 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.