I'm developing an application to keep some of the data in chronic patients, the data came from a very strict subset of data, vital signs, exams, ecc.
On a first glance I thought to create a Patient model with has_many encounters, and put every info in a different field like (age, height, weight, ecc), but it will result in a big model. So I wondered about embedding to make it easier to maintain and scale if in a couple of months I need to register a new exam, right now I have been thinking in something like this:
Patient
name: string,
address: string,
phone: integer,
diagnose: string,
etc...
Encounters
patient_id: ObjectID,
age: Integer,
vital_signs: [ { height, weight, bmi, systolic_pressure, diastolic_pressure } ],
exams: [ { creatinine, total cholesterol... } ],
next_encounter: Date
I'm going to still need to access to bmi
for example if I want to get how many people in the community is obese (hint: an awful lot), so embedding maybe it's not a very good idea. In any case, all the "analysis" will only be done only monthly (or less).
I picked mongodb, because I'm afraid the requisites for this database will be changing from time to time, so flexibility it's important.
Maybe in this case since data is structured, every document will have the same types of fields, a relational database could be better? I don't think it makes sense using a nosql database in a sql way, right?
PS.- I read this article from mongodb blog, and I'm more confused about if this really it's the best approach.