Discussion wanted: 'Trigger on Delete' cascade.

[R.Welz]

Hello.
I want to discuss a problem I have with my database design becourse I
feel I cannot decide wheather I am on the right way of doing things.

First of all, I am writing a literature and magazine database with web
(PHP) and C++ Interface, serving over the web and in a very fast LAN.
So my concern is about performance (and aestaetic by doing the things
as optimal as possible.) This is my first database at all, but I have
read a lot of books about it and I am a reasonable good C++ programmer.

So here is my problem...

I have table A and B and a linking table. I want to delete the linking
tables record, this should additionally delete a record in table A.
This can't be done with foreign key constraint, since the linking
tables record has the foreign key of table A, not the primary key.

Then table A depends on table B, and here is the same problem, table A
has the foreign key of table B, not the primary key.

and so on.
Actually I have several complex cases which have to do with automatic
deletion of tables with some tables involved, for example:
When you delete a magazine, you delete a corresponding e-mail from the
publisher, but only when this e-mail is not referenced anymore by other
tables, for example books , data storage disks, cds or the like.

So what I did was the following:

Delete linking table's record, this fires a trigger that deletes a
record in table A. Deletion in table A fires a trigger which checks if
table A's record references table B and is is allowed to be deleted. If
not, I RETURN NULL, if yes, I deletion is allowed to take place.

What do you think? Would it be better to have the trigger in the
linking table to check if it can safely delete record in A by checking
table B? Would that be a real performance gain?

Or are there ways of doing things, which I havn't thought about?

Thank you for thoughts on this subject.

Greetings,
Robert Welz
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Pierre-Frédéric Caillaud]

Display all headersTo: "R.Welz" <li***********@ gmx.de>
Subject: Re: [GENERAL] Discussion wanted: 'Trigger on Delete' cascade.
Date: Wed, 28 Jul 2004 13:24:26 +0200
From: Pierre-Frédéric Caillaud <li***@boutique numerique.com>
Organization: La Boutique Numérique

From what you say, your do not need a link table.
A link table is useful to link several items of a table to several items
of another table (many-to-
many relationship).

Example : items and categories.

1- An item belongs to a category
No need for a link table.
table categories ( id serial primary key );
table items ( category_id integer references categories( id ) on delete
cascade );

1- An item belongs to several categories
table categories ( id serial primary key );
table items ( id serial primary key );
table links (
category_id integer references categories( id ) on delete cascade,
item_id integer references items( id ) on delete cascade,
);
In this case you do need a link table.

You also need triggers to delete items when
- a link is deleted from the links table
- no more links to this item exist
which is, in fact, reference counting.





---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[R.Welz]

Yes.
A magazine can have several e-mail addresses, and one e-mail address
can belong to several magazines. Well, the e-mail addresses belongs to
the publisher but for simplification the e-mail address is linked with
the magazine.
So what is really more important is that I don't know, is there a big
performance penalty of the sort of "trigger calling another trigger" or
would it be noticeable faster if the first trigger does all the
checking and decides itself wheather to delete table B.

I think of writing a really large database, so performance is most
important, or will there be no noticeable performance hit? It is my
first big database.

Thank you
Robert

Am 28.07.2004 um 13:24 schrieb Pierre-Frédéric Caillaud:

From what you say, your do not need a link table.
A link table is useful to link several items of a table to several
items of another table (many-to-many relationship).

Example : items and categories.

1- An item belongs to a category
No need for a link table.
table categories ( id serial primary key );
table items ( category_id integer references categories( id ) on
delete cascade );

1- An item belongs to several categories
table categories ( id serial primary key );
table items ( id serial primary key );
table links (
category_id integer references categories( id ) on delete cascade,
item_id integer references items( id ) on delete cascade,
);
In this case you do need a link table.

You also need triggers to delete items when
- a link is deleted from the links table
- no more links to this item exist
which is, in fact, reference counting.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly