<mark@mark.mielke.cc> writes:
> On Wed, Mar 14, 2007 at 02:28:03PM +0000, Gregory Stark wrote:
>> "David Fetter" <david@fetter.org> writes:
>> > CREATE TABLE symptom (
>> > symptom_id SERIAL PRIMARY KEY, /* See above. */
>> > ...
>> > );
>> >
>> > CREATE TABLE patient_presents_with (
>> > patient_id INTEGER NOT NULL REFERENCES patient(patient_id),
>> > symptom_id INTEGER NOT NULL REFERENCES symptom(symptom_id),
>> > UNIQUE(patient_id, symptom_id)
>> > );
>>
>> I'm just glad I don't have your doctor. I hope mine doesn't think symptoms are
>> all boolean values.
>
> Where is the boolean above? It is M:N, with each having whatever data
> is required.
No, the above schema can only show whether a patient has or doesn't have a
symptom. There is nowhere to store *where* the pain, inflammation, swelling,
aneurism, etc is, or how severe it is, or when it occurred, etc.
In any case the above arguably *is* an EA schema anyways. Your "symptom" is
just as much an abstract meaningless concept from a database point of view as
the questionnaire's "answer" or the bug tracker's "tag". Especially once you
start actually having to record information *about* the symptom.
This is a silly argument. The only reasonable conclusion is that any dogmatic
principle that doesn't take into account the application requirements is
wrong. In some cases you want a flexible abstract schema because the
application is flexible and abstract, in others you need the database schema
to understand your specific data structures so it can help you manipulate it.
You have to pick which is more useful for your application, you can't have
your cake and eat it too.
And all of the sudden I have a craving for cake...
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com