Is my ER Diagram correct? Why use relationships? This is the first time I've made an Entity Relationship Diagram (ERD) for database that will be built on MySQL. The business domain of relevance is about equipment issues management.

Prior to this, I would never create relationships between tables, I would simply create the tables in MySQLAdmin and do the linking in my PHP/MySQL code.

Is there a reason why I should create these relationships?

I have read a lot of info on database design and relationships.

I want to be sure the ERD I've created is correct; did I make mistakes? Or are there better ways to do this?

The ERD under consideration



What my database should do:


I have a list of users (users) that can create tickets (issue_tickets).
They will give a description of the problem, maybe add some files (issue_files).
Then other users (issue_watchers) will be attached to solve the problem.
All the users (users) can comment on a ticket (issue_tickets).
A ticket (issue_tickets) only has one status (issue_status) at a time.
A ticket (issue_tickets) only has one category (issue_category).
A ticket (issue_tickets) can have many comments (issue_comments) and many watchers (issue_watchers)
A ticket (issue_tickets) only has one user (users) who created the ticket.
A ticket (issue_tickets) only applies to one equipment (equipment).
A user can create many tickets
An equipment can have many tickets
It is a very poor practice to expect to maintain the PK/FK relationships from the application. In any db that is nontrivial, data has close to a 100% chance of being changed from other sources including ad hoc queries, data imports, etc. It is irresponsible to think the data in the database is protected because the application has protections. Sure you think that you will force all changes through a webservice or some such, but the reality is that no one is going to add a million new customer records, from that company you just bought, one record at a time through a service. Your database has to be designed to account for the fact that people will change it directly at the source or through other applications (some of which may not be able to use your web service). Further, the application interface is usually more likely to be thrown away or redesigned than the data and when that happens, you may lose all or some of the data integrity rules. In designing databases, you have to think about how the data needs to be protected over time not about what is easiest and most convenient for the programmer or the intial application.  A data professional sets up PK/FK relationships in the database because that is where the data lives and it is the best place to set it up to protect the data quality.

I see data from a lot of different companies in my current position and I see all too many  that didn't set up their PK/FK relationships in the database because they have data integrity problems that a correctly designed database would not have.