mir ist gerade folgender Fehler passiert:
Es gibt zwei Tabellen (jeweils mit primary key) wobei die Zweite mit einer Spalte den primary key der
Ersten referenziert. Bloederweise habe ich mich vertippt und stattdessen beide primary keys verglichen.
Jetzt meine Frage: laesst sich das verhindern (ausser durch Aufmerksamkeit) ?
Z.B. indem statt “int” ein eigener Datentyp erzeugt wird der sich genauso verhaelt wie “int” aber nur mit
sich selbst verglichen werden kann.
Im SQL Standard ist so was vorgesehen (“distinct types”), leider wird das in Postgres nicht unterstützt (DB2 kann das…)
Auch mit Domains kommt man da nicht weiter.
Es steht seit einiger Zeit auf der Postgres TODO Liste - aber offensichtlich hat sich noch niemand gefunden, der das entwickelt.
@cwe
Es gibt m.E. etwas sehr simples, dass es- je nach “Liebe”, die man reinsteckt- im Datenmodell sehr gut “verhindert”. Es gibt keine Fehler und die Verhinderung ist auch nicht dramatisch, falsche Joins ergeben einfach leeres Ergebnis.
Das Zauberwort sind sequenzen und zwar nur eine für alles, eigentlich schon langweilig banal.
Es gibt natürlich Binär- Ästheten, die kontinuierlich nahtlose, aufsteigende, usw. PK Zahlen haben wollen (müssen), aber das ist kein allgemeines Gesetz, technisch ist nur Eindeutigkeit gefordert.
Was dagegen sprechen würde wäre vielleicht der verfügbare Range oder die Fähigkeiten der DB, aber beides greift nicht wirklich, bzw. sehr sehr lange nicht bei Postgres.
Man verliert vielleicht etwas “Komfort” beim Anlegen eines Models, aber das vermisse ich nicht.
In der Realität nutze ich nicht wirklich eine Sequenz, sondern sagen wir Domainen spezifisch jeweils eine. Das ist aber schon wieder “gefährliche” Bequemlichkeit, die daher resultiert, dass ich Modulbauweise möchte, Unabhängigkeit. Kann man natürlich machen, wie man möchte.
@pogomips: Sequences vereinfachen die Erstellung solcher Werte, aber sie verhindern nicht, dass man z.B. die Kundentabelle und die Produkttabelle über die Primary Keys joined - und darum geht es hier:
Nehmen wir mal diese Tabellen:
create table product (id integer primary key);
create table customer (id integer primary key);
create table orders (
id integer primary key,
product_id integer not null references product,
customer_id integer not null references customer
);
Und die folgende Abfrage:
select c.id, count(o.id) as num_orders
from customer c
join orders o on c.id = o.id --<< das müsste eigentlich o.customer_id sein!
group by c.id;
Der Join “funktioniert” natürlich weil beide Datentypen identisch sind und mit hoher Wahrscheinlichkeit auch die gleichen Werte enthalten. Er macht aber keinen Sinn und liefert ein völlig falsches Ergebnis - und das möchte cwe vermeiden. Wie die Werte für die id Spalten generiert werden ist dabei unerheblich.
Mit den “distinct types” aus dem SQL Standard könnte man so etwas machen:
create type t_product_id as integer;
create type t_order_id as integer;
create type t_customer_id as integer;
create table product (id t_product_id primary key);
create table customer (id t_customer_id primary key);
create table orders (
id t_order_id primary key,
product_id integer not null references product,
customer_id integer not null references customer
);
Wenn man jetzt die ID Spalten miteinander vergleicht, wird das als Fehler gewertet - ähnlich wie der Vergleich zweier Datentype die nicht kompatibel sind.
Danke fuer die Antworten. Die ‘distinct types’ sind in der Tat was ich suchte - vielleicht implementiert Postgres die ja eines Tages.
Die Idee mit einer Sequence fuer beide primary keys hatte ich auch und eine leere Menge ist sicher besser als falsche Ergebnisse.
Leider ist es jetzt etwas zu spaet dafuer, alle Datenbanken bei meinen Kunden umzustellen ist mir zu aufwendig.
Aber mein Testsystem ist jetzt umgestellt, so dass der Fehler sofort auffallen sollte.