Re: Design problemi : using the same primary keys for inherited objects. - Mailing list pgsql-sql

From David Pradier
Subject Re: Design problemi : using the same primary keys for inherited objects.
Date
Msg-id 20051017141353.GF19930@clarisys.fr
Whole thread Raw
In response to Re: Design problemi : using the same primary keys for inherited objects.  ("codeWarrior" <gpatnude@hotmail.com>)
Responses Re: Design problemi : using the same primary keys for inherited
List pgsql-sql
Well yes, i find your system very interesting and will maybe use it as
solution for another problem we have ( :-) ), but i fail to see where
it makes use of a primary key referencing another primary key ?


On Fri, Oct 14, 2005 at 08:29:40AM -0700, codeWarrior wrote:
> I dont consider this to be a design problem... In fact... I do the inherited 
> table thing pretty routinely... It (table inheritance) works very well if 
> you need to implement a Sarbanes-Oxley audit trail or a "virtual" rollback 
> system without the overhead of managing transactions.
> 
> Consider the relationship between a company (sys_client) and the company's 
> employees (sys_user). An inheritance model in postgreSQL is a very efficient 
> mechism to ensire that user entries "roll-up-to" or are "owned" by a client 
> entry in the parent table. Here's a short example:
> 
> If you wish -- you can execute the following DDL.
> 
> CREATE TABLE sys_client (
> 
>  id SERIAL NOT NULL PRIMARY KEY,
> 
>  c_name VARCHAR(72),
>  lu_client_type INTEGER NOT NULL DEFAULT 4 REFERENCES lu_client_type,
>  lu_support_program INTEGER NOT NULL REFERENCES lu_support_program(id),
> 
>  create_dt TIMESTAMP NOT NULL DEFAULT NOW(),
>  change_dt TIMESTAMP NOT NULL DEFAULT NOW(),
>  change_id INTEGER DEFAULT 0,
>  active_flag BOOLEAN NOT NULL DEFAULT TRUE
> 
> ) WITH OIDS;
> 
> CREATE TABLE lu_user_type (
> 
>  id serial NOT NULL PRIMARY KEY,
>  type_desc varchar(72) NOT NULL,
>  can_delete bool DEFAULT false,
> 
>  create_dt timestamp NOT NULL DEFAULT now(),
>  change_dt timestamp NOT NULL DEFAULT now(),
>  change_id INTEGER NOT NULL DEFAULT 0,
>  active_flag bool NOT NULL DEFAULT true
> 
> ) WITH OIDS;
> 
> INSERT INTO lu_user_type(type_desc) VALUES ('Administrator');
> INSERT INTO lu_user_type(type_desc) VALUES ('User');
> INSERT INTO lu_user_type(type_desc) VALUES ('Restricted user');
> INSERT INTO lu_user_type(type_desc) VALUES ('Demo');
> INSERT INTO lu_user_type(type_desc) VALUES ('Demo - admin');
> 
> CREATE TABLE sys_user (
> 
>  sys_client_id INTEGER NOT NULL REFERENCES sys_client(id),
>  lu_client_group INTEGER references sys_client_group(id),
> 
>  lu_user_type INTEGER NOT NULL REFERENCES lu_user_type(id),
>  f_name VARCHAR(50) NOT NULL,
>  m_name VARCHAR(50),
>  l_name VARCHAR(50) NOT NULL,
>  email_addr VARCHAR(120) NOT NULL,
>  uname VARCHAR(20) NOT NULL,
>  upwd VARCHAR(20) NOT NULL,
> 
>  login_allowed BOOLEAN DEFAULT true,
>  reset_pwd BOOLEAN DEFAULT false,
>  pwd_change_reqd bool DEFAULT false,
>    lost_passwd bool DEFAULT false
> 
> ) INHERITS (sys_client);
> 
> 
> CREATE TABLE sys_user_history (
> 
>        hist_id SERIAL NOT NULL PRIMARY KEY,
>        hist_dt TIMESTAMP NOT NULL DEFAULT NOW()
> 
> ) INHERITS (sys_user);
> 
> CREATE OR REPLACE RULE sys_user_history AS ON UPDATE TO sys_user DO INSERT 
> INTO sys_user_history (SELECT * FROM ONLY sys_user WHERE id = OLD.id);
> 
> CREATE TABLE sys_user_login (
> 
>   id serial NOT NULL PRIMARY KEY,
> 
>   sys_client INTEGER NOT NULL REFERENCES sys_client(id),
>   login_date timestamp NOT NULL DEFAULT now(),
>   valid_until timestamp NOT NULL DEFAULT (now() + '00:20:00'::interval),
>   session_id varchar(32) NOT NULL UNIQUE,
> 
>   create_dt timestamp NOT NULL DEFAULT now(),
>   change_dt timestamp NOT NULL DEFAULT now(),
>   change_id int4 NOT NULL DEFAULT 0,
>   active_flag bool NOT NULL DEFAULT true
> 
> ) WITH OIDS;
> 
> 
> insert into sys_client(c_name) VALUES ('Mattel');
> insert into sys_client(c_name) VALUES ('Hasbro');
> insert into sys_client(c_name) VALUES ('Lego');
> 
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (1, 1, 'Arnold', 'Antione', 'Aardvaark', 
> 'arnold@spam.com', 'arnie', 'arnie');
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (1, 2, 'Roberto', 'Guiterrez', 'Amendola', 
> 'roberto@spam.com', 'arnie', 'arnie');
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (2, 1, 'Albert', '', 'Einstien', 
> 'albert@spam.com', 'albert', 'albert');
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (2, 2, 'David', 'C', 'Davidson', 
> 'david@spam.com', 'david', 'david');
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (3, 1, 'Marilyn', '', 'Monroe', 
> 'mmonroe@spam.com', 'mmonroe', 'mmonroe');
> INSERT INTO sys_user(sys_client_id, lu_user_type, f_name, m_name, l_name, 
> email_addr, uname, upwd) VALUES (3, 2, 'Fred', 'E', 'Flintstone', 
> 'fred@spam.com', 'fred', 'fred');
> 
> 
> 
> SET SQL_INHERITANCE = ON;
> 
> -- RUN EACH OF THESE QUERIES IN SUCESSION TO SEE HOW IT REALLY WORKS...
> SELECT * FROM sys_client;
> SELECT * FROM ONLY sys_client;
> SELECT * FROM sys_user;
> SELECT * FROM ONLY sys_user;
> 
> SELECT SC.id AS client_id, SC.c_name, SU.id AS employee_id, SU.f_name, 
> SU.l_name FROM sys_client SC JOIN sys_user SU ON SU.sys_client_id = SC.id;
> 
> 
> 
> "David Pradier" <david.pradier@clarisys.fr> wrote in message 
> news:20051014091829.GB19930@clarisys.fr...
> > Hi everybody,
> >
> > i've got a strange design question to ask you.
> > It's something I couldn't answer to while feeling confusely it was an
> > absolutely BAD thing to do.
> >
> > For our application, we have developed our own framework which sits on
> > top of PostgreSQL. It uses object programming and implements heritage.
> > Inherited objects use heritage links in the framework and relation links
> > in PostgreSQL (Search me why it doesn't use heritage in PostgreSQL !?).
> >
> > I've got this thing :
> > An object A inherits from an object B, which inherits from a object C,
> > which inherits from an object D.
> > One of my colleagues proposed that we don't use serial (integer +
> > sequence) primary keys for these objects, but that we use the very same
> > integer primary keys.
> > That is : the instance A would use the id 12343, and the instance B the
> > same id 12343 and the instance C the same id 12343 and the D instance the
> > same id 12343.
> >
> > It's possible as two instances of an object never inherit from a same
> > instance of another object.
> >
> > The id seems to me absolutely bad, but I wouldn't know how to phrase
> > why.
> >
> > Any suggestion ?
> >
> > Thanks in advance,
> > David.
> >
> > -- 
> > David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de 
> > projet logiciels libres / open-source
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> >               http://www.postgresql.org/docs/faq
> > 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

-- 
David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source


pgsql-sql by date:

Previous
From: David Pradier
Date:
Subject: Re: Design problem : using the same primary keys for inherited objects.
Next
From: Richard Huxton
Date:
Subject: Re: Design problemi : using the same primary keys for inherited