OOP real life example (was Re: Why is MySQL more chosen over PostgreSQL? - Mailing list pgsql-hackers
From | Daniel Lyons |
---|---|
Subject | OOP real life example (was Re: Why is MySQL more chosen over PostgreSQL? |
Date | |
Msg-id | 20020809105716.GA32345@nmt.edu Whole thread Raw |
Responses |
Re: OOP real life example (was Re: Why is MySQL more chosen
(Curt Sampson <cjs@cynic.net>)
|
List | 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. *)
pgsql-hackers by date: