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
time. :-)
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.
Cheers,
mark
--
[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...
http://mark.mielke.cc/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
