[SQL] Inheritance (general hints wanted)
Hi, I think i have reached a point in my PgSQL years that i am seriously thinking of using inheritance. The situation is simple: An new entity (tanker vessels crew) is about to be modeled, and i suspect there will be a future need to include the rest of 'workers' besides 'sailors', IOW i suspect a future need to generalize. So i am thinking of a two-level tree hierarchy, where there is a simple table emp (employee), and a direct child 'tankerscrew'. Later there may be 'masons', 'office_employees' and so on. The problem is that while i find this approach attractive, i have never used PostgreSQL inheritance exhaustively and in production scale. Furthermore, i also feel that not many people have used inheritance in a massive fashion (besides playing with a test db). Of course i can do it with separate uncoupled tables, that can be later related with some views. So that leads to the final question: -What are the main PROs of inheritance that cant be beat by other solutions, and -Are there any traps someone must have in mind when he prepares for such a design? Thanx in advance. -- -Achilleus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Inheritance (general hints wanted)
Hi, I am not an expert but in object conception, a design pattern exists for the case you describe. I don't remember which one. The idea is to add an attribute that references the job of the employee. The inheritance is not on the side of the employee but on the side of the job. So if the job of the employee changes, it easy to do it. an example in pseudo-code class basic_job string name class sailor_job inherit basic_job class employee string name basic_job job Hope it helps, Regards, Thomas > > Hi, > > I think i have reached a point in my PgSQL years > that i am seriously thinking of using inheritance. > > The situation is simple: An new entity (tanker vessels crew) > is about to be modeled, and i suspect > there will be a future need to include > the rest of 'workers' besides 'sailors', > IOW i suspect a future need to generalize. > > So i am thinking of a two-level tree hierarchy, > where there is a simple table emp (employee), > and a direct child 'tankerscrew'. Later > there may be 'masons', 'office_employees' > and so on. > > The problem is that while i find this approach > attractive, i have never used PostgreSQL > inheritance exhaustively and in production scale. > > Furthermore, i also feel that not many > people have used inheritance in a massive fashion > (besides playing with a test db). > > Of course i can do it with separate uncoupled tables, > that can be later related with some views. > > So that leads to the final question: > -What are the main PROs of inheritance that cant be beat > by other solutions, and > -Are there any traps someone must have in mind when he > prepares for such a design? > > Thanx in advance. > -- > -Achilleus > > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > A+ Tom Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] Inheritance (general hints wanted)
O Achilleus Mantzios έγραψε στις Sep 20, 2005 : > > Hi, > > I think i have reached a point in my PgSQL years > that i am seriously thinking of using inheritance. > > The situation is simple: An new entity (tanker vessels crew) > is about to be modeled, and i suspect > there will be a future need to include > the rest of 'workers' besides 'sailors', > IOW i suspect a future need to generalize. > > So i am thinking of a two-level tree hierarchy, > where there is a simple table emp (employee), > and a direct child 'tankerscrew'. Later > there may be 'masons', 'office_employees' > and so on. Each table may be managed by its own applications, whereas the accounting software will only need to read and *update* the generic top level 'employee' table. That would be great but unfortunately it isnt how it works in PostgreSQL currently... If PRIMARY KEYS were to be shared, a great future (real) feature would be a "isinstanceof" -like function on the PRIMARY KEY, which tells if a row of the specific PK is from a certain table in the hierarchy. > > The problem is that while i find this approach > attractive, i have never used PostgreSQL > inheritance exhaustively and in production scale. > > Furthermore, i also feel that not many > people have used inheritance in a massive fashion > (besides playing with a test db). > > Of course i can do it with separate uncoupled tables, > that can be later related with some views. > > So that leads to the final question: > -What are the main PROs of inheritance that cant be beat > by other solutions, and > -Are there any traps someone must have in mind when he > prepares for such a design? > > Thanx in advance. > -- -Achilleus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] Inheritance (general hints wanted)
Judging from the replies i got, it seems that inheritance is even less used than i initially thought. I think that the OO term is a little too much advertised in pgsql advocacy various acts, than actually engineered. However, OO in pgsql besides being a traditionally cool acronym, it also *could* prove to be extremely useful when dealing with real problems. Just a question, to all those who have implemented inheritance in pgsql: Are there any plans for dealing with the current problems? Is it foundamentally hard to fix these problems? -- -Achilleus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
