I'm relatively new to databases so I apologize if there's an obvious way to approach this or if there is some fundamental process I'm missing. I'm using PHP and MySQL in a web application involving patient medical records. One requirement is that users be able to view and edit the medical records from a web page.
As I envisage it, a single Patient
object has basic attributes like id
, name
, and address
, and then each Patient
also has an array of Medication
objects (med_name, dose, reason
), Condition
objects (cond_name, date, notes
), and other such objects (allergies, family history, etc.). My first thought was to have a database schema with tables as follows:
- patients (id, name, address, ...)
- medications ( patient_id, med_name, dose, reason)
- conditions ( patient_id, cond_name, date, notes)
- ...
However, this seems wrong to me. Adding new medications or conditions is easy enough, but deleting or editing existing medications or conditions seems ridiculously inefficient - I'd have to, say, search through the medications
table for a row matching patient_id
with the old med_name
, dose
, and reason
fields, and then delete/edit it with the new data. I could add some primary key to the medications
and conditions
tables to make it more efficient to find the row to edit, but that would seem like an arbitrary piece of data.
So what if I just had a single table with the following schema?
- patients (id, name, address, meds, conds, ...)
Where meds
and conds
are simply representations (say, binary) of arrays of Medication
and Condition
objects? PHP can interpret this data and fetch and update it in the database as needed.
Any thoughts on best practices here would be welcome. I'm also considering switching to Ruby on Rails, so if that affects any decisions I should make I'm interested to hear that as well. Thanks a lot folks.