On Thu, Feb 26, 2004 at 15:22:37 +0100,
Michiel Lange <michiel@minas.demon.nl> wrote:
> But here it is:
> I have a database that is about how ocomputers and phones are connected
> in a patch panel.
> For that I have three tables:
> patches(patch_id(serial, pkey), location(varchar, unique));
> computers(computer_id(serial, pkey), name(varchar, unique), patch
> (unique,references patches.patch_id), ... and some more);
> phones(number(int4, pkey), owner(varchar), patch (unique,references
> patches.patch_id), ... and some more);
>
> (the database is not only about this information, there's quite some
> more, but this narrows the problem down)
>
> The point is:
> I can say that computers.patch is unique
> I can also say that phones.patch is unique
>
> but there's also this situation that you cannot connect a computer and a
> phone on the same patch_id, so if a patch is used for a computer it is
> not possible to use that patch also for the phones. (and vise versa)
> As far as I know there is no constraint that enforces this, so I will
> have to write a trigger...
You can enforce this without having to write a trigger.
You add a patch type to all three tables constrained in patches to be
one of two types and in the other tables to be the type matching that
table. Then you make the foreign keys into patches to be patch_id
combined with the patch type. This prevents both phones and computers
from having the same patch id.
