On Jun 3, 11:02 am, Kalpa Welivitigoda <callka...@gmail.com> wrote:
> Hi,
>
> I want to develop a web based laboratory test reporting system. It
> basically involves storing the records of different tests for
> different patient and get a print out of the reports. There are around
> 100 tests with different fields.
>
> The flow would be that the user enters a patient id and the tests for
> that person appears, then he selects one test and a input form appears
> to enter test results. This continues for the other tests as well and
> finally a print out is issued and a pdf of the report is generated on
> request.
>
> Since there are around 100 tests (with different fields), do I need to
> write separate models and views (to view the data input form) for each
> and every one of them or can it be made simpler at least generating
> views (because views are generated from some of the fields in the
> model) ?
There are a couple of ways to go forward I know of.
The simplest pattern is just to have all the tests as Models. This is
likely a road of a lot of pain to maintain, but it is definitely worth
trying if this works for you. Creating new Python models isn't that
complicated, and with South migrations are somewhat easy to do, too.
Another somewhat common pattern is to use EAV (entity-attribute-value)
style tables. The modeling would be something like:
class Patient:
<patient_info>
class Test:
<test_info>
class PatientTest
FK(patient)
FK(test)
class PatientTestResult
FK(PatientTest)
attr_type
attr_value
So, for each patient - test combo you can store attributes of that
test. It is somewhat common to then model also metadata of what
attributes each test can potentially have, so that you can dynamically
construct the forms and/or create procedures which validate the data.
This can feel like a clever way forward, but my personal experience is
that this is actually going to be a pain to maintain. Another problem
is that most trivial queries easily becomes an unholy mess of joins +
subselects (or you need PIVOT queries, or something else like that).
For example I have a EAV system to maintain where querying pretty
basic information about an employee requires 50+ joins.
Consider carefully before going down the EAV road. Avoid storing any
validation logic in the database.
I would likely try to go with a format where you store the test
results in JSON/XML/HStore(if using PostgreSQL)/some other vendor
specific datatype. If you need to do calculations on the test results,
you can then transform the serialized format to (denormalized)
database tables for the calculations. If this transformation feels
like a lot of work, remember that if you have EAV you will still need
to do this, or write queries you really don't want to be writing. If
you have some common attributes (identifier code, date of test,
location of test, the person who did the test, etc) then model these
into SQL tables. Just the result fields should go into the serialized
format.
This is one area where there really aren't any right answers. You need
to prototype what works for your use case.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
