Dotaz: PostgreSQL a dědičnost

[xkucf03]

Ahoj. Chtěl jsem použít dědičnost v PostgreSQL tak, abych měl tabulku obecných objektů (předka) a pak tabulku článků (potomek) a později další potomky objektů. S tím, že na objekty bych třeba mohl navázat komentáře nebo hodnocení a nemusel bych tohle dělat pro každého potomka zvlášť.

Tabulky vypadají takhle:

CREATE TABLE objekt
(
  id numeric NOT NULL, -- Identifikace jedinečná pro všechny objekty v systému
  nazev character varying, -- Název objektu
  CONSTRAINT objekt_pk PRIMARY KEY (id)
)
WITH (OIDS=FALSE);
ALTER TABLE objekt OWNER TO piskoviste;
COMMENT ON COLUMN objekt.id IS 'Identifikace jedinečná pro všechny objekty v systému';
COMMENT ON COLUMN objekt.nazev IS 'Název objektu';

CREATE TABLE clanek
(
-- Inherited:   id numeric NOT NULL,
-- Inherited:   nazev character varying,
  "text" text, -- Text článku
  CONSTRAINT clanek_pk PRIMARY KEY (id)
)
INHERITS (objekt)
WITH (OIDS=FALSE);
ALTER TABLE clanek OWNER TO piskoviste;
COMMENT ON COLUMN clanek."text" IS 'Text článku';

Problém ale je, že primární klíč funguje jen na danou tabulku, např. předka a nezabrání tomu, abych měl objekt s id = 1 a článek s id = 1 a pak když selektuji všechny objekty (včetně článků), dostanu výstup s duplicitními id.

Další problém bude s cizími klíči, když budu chtít navázat třeba ty komentáře na objekt.

Samozřejmě jsem udělal RTFM a zjistil jsem, že oficiální dokumentace tyhle problémy popisuje. Řešení ale chybí, jen se tam píše, že tyhle nedostatky budou napraveny někdy v příštích verzích.

Existuje nějaký způsob, jak dědičnost využít k mému účelu, nebo se na to mám vykašlat a udělat to klasicky*? Případně použít jako identifikátor OID? Ale nevím, jak moc dobré řešení to je (řešilo by to PK, ale ne FK).

*) Víc tabulek provázaných přes cizí klíče, kde „potomci“ budou mít jako PK cizí klíč do tabulky „předka“ + nějaké pohledy, které udělají souhrn společných sloupečků všech potomků.

Odpovědi

[xkucf03]

BTW: tohle funguje podle mých představ:

SELECT o.*, pg_class.relname
FROM objekt o
JOIN pg_class ON (o.tableoid = pg_class.oid);

…seznam objektů včetně jejich typu (resp. názvu tabulky)

[xkucf03]

Ještě před usnutím mě jedno řešení napdalo: vytvořím si pomocnou tabulku objekt_id, která bude obsahovat seznam ID objektů, a funkci zalozObjekt(), která vezme nové ID ze sekvence a zároveň založí záznam v objekt_id. Tuhle funkci použiji jako výchozí hodnotu sloupečku místo přímého selektování sekvence.

CREATE SEQUENCE komentar_seq
  INCREMENT 1
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 1
  CACHE 1;

CREATE SEQUENCE objekt_seq
  INCREMENT 1
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 2
  CACHE 1;

CREATE TABLE objekt_id
(
  id bigint NOT NULL,
  CONSTRAINT objekt_id_pk PRIMARY KEY (id),
  CONSTRAINT objekt_fk FOREIGN KEY (id)
      REFERENCES objekt_id (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
COMMENT ON TABLE objekt_id IS 'Tabulka navíc, abychom obešli problém s PK a dědičností.
Žádná data, jen seznam primárních klíčů objektů';

CREATE OR REPLACE FUNCTION zalozobjekt()
  RETURNS bigint AS
$BODY$DECLARE id BIGINT;
BEGIN
    SELECT INTO id nextval('objekt_seq');
    INSERT INTO objekt_id VALUES (id);
    return id;
END;$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;

CREATE TABLE objekt
(
  id bigint NOT NULL DEFAULT zalozobjekt(), -- Identifikace jedinečná pro všechny objekty v systému
  nazev character varying, -- Název objektu
  CONSTRAINT objekt_pk PRIMARY KEY (id),
  CONSTRAINT clanek_fk FOREIGN KEY (id)
      REFERENCES objekt_id (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
COMMENT ON COLUMN objekt.id IS 'Identifikace jedinečná pro všechny objekty v systému';
COMMENT ON COLUMN objekt.nazev IS 'Název objektu';

CREATE TABLE clanek
(
-- Inherited:   id bigint NOT NULL,
-- Inherited:   nazev character varying,
  "text" text, -- Text článku
  CONSTRAINT clanek_pk PRIMARY KEY (id)
)
INHERITS (objekt)
WITH (OIDS=FALSE);
COMMENT ON COLUMN clanek."text" IS 'Text článku';

CREATE TABLE komentar
(
  id bigint NOT NULL DEFAULT nextval('komentar_seq'::regclass),
  nadpis character varying NOT NULL,
  "text" text NOT NULL,
  objekt bigint NOT NULL,
  odpoved_na bigint,
  CONSTRAINT komentar_pk PRIMARY KEY (id),
  CONSTRAINT komentar_objekt_fk FOREIGN KEY (objekt)
      REFERENCES objekt_id (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT komentar_odpoved_fk FOREIGN KEY (odpoved_na)
      REFERENCES komentar (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);

CREATE INDEX fki_komentar_objekt_fk
  ON komentar
  USING btree
  (objekt);

CREATE INDEX fki_komentar_odpoved_fk
  ON komentar
  USING btree
  (odpoved_na);

CREATE OR REPLACE VIEW trida_objektu AS
 SELECT o.id, o.nazev, pg_class.relname
   FROM objekt o
   JOIN pg_class ON o.tableoid = pg_class.oid;

Zatím to vypadá, že to funguje – řeší to problém jedinečnosti ID přes předka a všechny potomky a problém s cizími klíči (např. navázání komentářů).
Ale přijde mi to jako dost velká obebávka, tak by mě zajímalo, co si o tom myslí Pavel Stěhule nebo někdo podobný

[Pavel Stěhule]

S dědičností je to asi tak - když jsem si poprvně přečetl manuál, řekl jsem si super. A než jsem se dostal k projektu, kde bych ji mohl použít, tak jsem krapet vystřízlivěl. Dědičnost má smysl, tam kde mám dynamické schéma - tj. kde využiju toho, že po přidání potomka vidím data i v rodiči. Jinak nevidím důvod ji použít. A ohledně té obebavky - s Petrem Krontorádem http://www.krontorad.com/ jsme vymýšleli objektový db backend pro menší aplikace. Výsledná struktura byla docela podobná. Šli jsme na to o fous univerzálněji - měli jsme popisný jazyk pro popis objektů - skripty v něm se po vykonání přeložily v SQL příkazy, které jednak vytvářely podobné schéma, jednak plnily tabulky s metadaty, vytvářely potřebné indexy, atd.

Funkci zaloz_objekt bych asi napsal o něco úsporněji (všechny tři příkazy lze sloučit do jednoho pomocí klauzule RETURNING):

 

[xkucf03]

Díky za odpověď. Schchéma až tak dynamické nebude, ale asi u dědičnosti zůstanu, pokud se neobjeví nějaký velký problém (líbí se mi např. ten snadný způsob zjištění typu objektu pomocí pohledu).

Ještě bych měl dotaz: nějak cítím, že by bylo systémově lepší, kdyby potomkem objektu byly úplně všechny objekty v systému (včetně komentářů, hlasování atd.). Ale tyhle věci jako objekty mít nepotřebuji a navíc se obávám, že by tabulka objekt_id narostla do zbytečně velkých rozměrů a nic by to nepřineslo. Naopak by její velikost mohla způsobovat zpomalení. Co bys volil ty – univerzální řešení (všechno je potomkem objektu) nebo mít jako objekty jen ty tabulky, u kterých to má smysl?

 

 

[okbob]

To vubec nedokazu rict - je to otazka citu - treba komentare beru spise jen jako property u clanku (ale zalezi na kontextu). Pokud uz bych ale pracoval s objekty - tak spis bych vychazel z jednoho predka - to ostatni bych vubec nepovazoval za objekty.