Help/Critique ERD

[Aaron4osu]

I was hoping I could get someone to look at my ERD and let me know if it looks ok. Below is an explanation and I attached a pdf of my erd.

I'm creating a website where a user can:

 

1)create a profile

2)then have the ability to create many projects.

each project along with the other fields will have drop down menus for:

-Genre

-Format

-Status

 

3) The project creator will assign positions needed for the project.

The project crew table will have a drop down menu (crew positions) with types of crew positions (producer, director, etc...). Until a position is filled it will have an open to apply status. When the position is filled the users name will appear for that position.

 

4) Each Project Crew Position(in the project crew table) will have many users apply to that position. They will be stored in the audition table.

 

Anyway, I hope this makes sense. If you have any questions I'll be monitoring this closely and get respond quickly. Thanks

17588_.pdf

[thehippy]

Design wise, its fine, its a simple place to start off from.

 

Couple things though.

 

Will options be shared across entire application? For instance the genres will they be supplied by the user? If so, do you show all users everyone elses' genres?  Its a simple thing to make private.

 

Users like choices, having a single choice for Project.Genre for example, I foresee you getting a request down the line to add the ability to have multiple genres.  Project Crew.crew_status, users will probably want to setup presets for different status levels.  More business minded users will also want to track history of things like status changes.  Consulting your client about user needs and expectations comes in handy with what you do and do not need.

 

Naming, yours is inconsistent.  Its very common to have repetitive column names, but a DBA will only yell at you if they're nice.  Format.format_title should just be Format.title, saves typing time, if similar attributes in JOINs are your concern use better aliases. 

 

Most DBs will not allow spaces in names, choose single word table names when possible.  Consult your DB docs about table naming, some just UPPER() table and attribute names, you can save a few CPU cycles if that's the case by having it done to begin with, thought not truly necessary.

 

No indexes indicated, fix that before I get a shovel out.

 

Do you intend your application to be multilingual?

 

Small things really, better than a lot of the things I've had to deal with.