Nicht vergleichbare Datentypen "erfinden"

Fragen und Probleme rund um die Abfragespache SQL.
Antworten
cwe
Neuer Benutzer
Beiträge: 2
Registriert: So 18. Jun 2017, 10:41

Nicht vergleichbare Datentypen "erfinden"

Beitrag von cwe » Do 31. Jan 2019, 13:59

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.

castorp
Erfahrener Benutzer
Beiträge: 1099
Registriert: Sa 27. Jun 2009, 22:24
Wohnort: Bayern

Re: Nicht vergleichbare Datentypen "erfinden"

Beitrag von castorp » Do 31. Jan 2019, 14:01

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.
A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

pogomips
Benutzer
Beiträge: 81
Registriert: Fr 18. Nov 2016, 09:55

Re: Nicht vergleichbare Datentypen "erfinden"

Beitrag von pogomips » Do 31. Jan 2019, 22:37

@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.

castorp
Erfahrener Benutzer
Beiträge: 1099
Registriert: Sa 27. Jun 2009, 22:24
Wohnort: Bayern

Re: Nicht vergleichbare Datentypen "erfinden"

Beitrag von castorp » Fr 1. Feb 2019, 09:20

@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:

Code: Alles auswählen

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:

Code: Alles auswählen

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:

Code: Alles auswählen

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.
A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

cwe
Neuer Benutzer
Beiträge: 2
Registriert: So 18. Jun 2017, 10:41

Re: Nicht vergleichbare Datentypen "erfinden"

Beitrag von cwe » Fr 1. Feb 2019, 21:03

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.

akretschmer
Erfahrener Benutzer
Beiträge: 7565
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Re: Nicht vergleichbare Datentypen "erfinden"

Beitrag von akretschmer » Fr 1. Feb 2019, 22:48

cwe hat geschrieben:
Fr 1. Feb 2019, 21:03
Danke fuer die Antworten. Die 'distinct types' sind in der Tat was ich suchte - vielleicht implementiert Postgres die ja eines Tages.

Du bist gerne eingeladen, dies zu unterstützen. Entwicklung neuer Features kostet IMMER Geld. Und es gibt in der Tat Firmen, die bereit sind, in die Entwicklung neuer Features zu investieren. Also, falls Du 'Butter bei die Fische' machen willst, kannst Du mich gerne kontaktieren.
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Antworten