Good practice for MySQL table design

Question

I am currently working on a healthcare project while I'm not very familiar with DB. As DB is the foundation of the project, I'm still struggling on it.

Here's my question. According to my experience, setting foreign key FK is good practice for database design. However, after deploying OpenEMR (an open source patient profile system), I saw tens of tables were created, while none of them has FK , even from patient_data to patient_profile .

Any reason for this?

Thanks in advance.

Answer 1

The database creation script of OpenEMR is using MyISAM as storage engine. MyISAM is not supporting FK natively (read http://dev.mysql.com/tech-resources/articles/mysql-enforcing-foreign-keys.html ) but InnoDB does ( http://dev.mysql.com/doc/refman/5.7/en/ansi-diff-foreign-keys.html ).

So it's just related to the choice of the sotrage engine at the beginning.

Answer 2

One reason we do not use foreign keys in one of our systems is that we import our data from a somewhat unreliable source system. The source system is responsible for maintaining the integrity.

But it sometimes fails at that. Often in a way that is not disastrous to our system, so we can still import the data. Often times the files we import are out of order constraint-wise so that we might get for example the patient journal records first and the patient themselves a few minutes later.

Adding up these two points we get that:

1. Our system can work in most cases where the database constraints would fail.
2. We are not responsible for the integrity anyway.

So there are few downsides to just continue operating our system with an constraint-compromised database (= not adding foreign keys), and if it for some reason fails it is not on our table to fix up the integrity.

One might ask why the source system cannot just fix its constraint problems, and that would be a perfectly valid question. That problem is economic-social and not technical in nature, though, and not fit for Stack Overflow.