On Wed, Mar 14, 2007 at 03:25:48PM +0000, Gregory Stark wrote:
> <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 14, 2007 at 02:28:03PM +0000, Gregory Stark wrote:
> >> "David Fetter" <[EMAIL PROTECTED]> 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.
What do you think the '...' is in the symptom table? :-)
I'm not saying I would do it that way - but it seems to me that this
is a bit of a religious debate, without people listening to each
other. For one person to suggest a workable solution, and another
person to write it off as quickly as you did, misunderstanding, or
misrepresenting it, is what I would call "not listening". :-)
> 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.
No. Another reasonable conclusion is that the answer is not simple. This
doesn't mean the answer is undesirable. It means that people need more
I prefer abstractions, especially if they are more efficient than if I were
to roll my own each time. Relational databases do a good job today. They can
do a better job tomorrow.
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?