From: | Daniel Lyons <fusion(at)nmt(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | OOP real life example (was Re: Why is MySQL more chosen over PostgreSQL? |
Date: | 2002-08-09 10:57:16 |
Message-ID: | 20020809105716.GA32345@nmt.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm a little out of my league on this list, but I thought I might discuss a
problem I'm having since it seems to have come up here recently. I have read
the archives w/ respect to the inheritance mechanism, the problems with it,
etc. But I still think it would be a useful thing to have in PostgreSQL, even
if the current implementation... leaves something to be desired. I
particularly think it could be useful for a problem I'm working on now.
I'm working on a largish Python-based voting system for my college. The
backend is to be PostgreSQL because of referential integrity, stored
procedures, etc.--the thousand good reasons you guys already know.
During the analysis phase we've noticed that there are really two kinds of
"questions" if you will, "position questions" and "binary questions." Things
like "Secretary" are position questions, and have a list of candidates
associated with them, and things like "Should the SA do such-and-such" are
binary questions.
Up at the top of the tree (kind of) is the election, which is an entity that
among other things contains a few sets of questions. Each set is for a
different population (graduates don't get to pick undergrad senators, for
example). Each question set refers to one or more questions, which can be one
of the two types I was just talking about.
The problem is that position questions are going to be referred to by the
candidate position table (a table that links candidates and positions in a
many-to-many way). The candidate position table therefore will be referencing
a primary key which the position question table inherits from the question
table.
So my initial thinking is that this is a profound problem. But after a little
more thought, I can make the question_id field of the question table be a
SERIAL type and the primary key. That way, when I insert rows into either
the position question or the binary question table, it will be picking the
values out of the same sequence. I won't have actual primary key integrity
checking, but I'm fairly safe in assuming that it won't be a problem.
Then my second thought was, perhaps I could write some sort of CHECK procedure
which would verify integrity by hand between the two tables. Or perhaps I
could manually state that the primary key was the question_id field when
creating both the child tables. I'm really not sure if any of these
approaches will work, or which one is best to do.
So now that I hear there is a way to get from an object-relational solution to
a solution using views, I'd like to know how to do it in general or perhaps
with my particular problem. I'm a big fan of OOP, as are the other people
working with me on this project, so I would (personally) rather work around
the existing inheritance mechanism than implement a solution I probably won't
understand later using views, though I'd like to know it also... what is your
advice?
--
Daniel
(* Obscenity is a crutch for inarticulate motherfuckers. *)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-09 13:50:13 | Re: pg_stat_reset() weirdness |
Previous Message | Nigel J. Andrews | 2002-08-09 10:12:55 | Re: [HACKERS] Linux Largefile Support In Postgresql RPMS |