Home/ Questions/Q 7052971
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T03:26:53+00:00

I’m designing a MySQL database for a startup working with patient medical records. I

  • 0

I’m designing a MySQL database for a startup working with patient medical records. I have several tables that can have no unique keys: medical conditions, allergies, family history, etc. For example the medications table might have fields patient_id, med_name, usage_dates, dosage, reason, etc. The only guaranteed unique key is all of the fields together.

A web application can easily retrieve this data for a given patient by selecting for patient_id, but unless it is possible to save pointers to rows inside a database with multiple users, it strikes me as a clumsy system for editing or deleting rows in this table. The DBMS would have to select for each field’s value in order to find the correct row. From what (little) I know about databases, I imagine this could be inefficient in a large database.

Would it be more efficient to create a new field with an ID number to function as a primary key in each of these tables, or is the DBMS way smarter than me and this is totally unnecessary?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can always add a simple numeric primary key (e.g. mysql auto_increment) so you DO end up with a unique identifier for each row. Composite primary keys are a serious pain if you have to use the table in a foreign key relationship, forcing you to list each of the primary key’s component’s field’s in all joins/FK specifications. By comparison, adding a simple int primary key reduces you to carrying that ONE field around for the FK/join relationships.

    I’d suggest something along the lines of:

    patients (id, name, ....)
meds (id, brand, name, ...)
patient_meds (patient_id, med_id, dosage, ...)
    • 0