Fehlerhaften ForeinKey finden

[Perlsau]

Moin allerseits,

in einer DB gibt es eine Tabelle ADRESSEN, die eine Spalte ORT_ID enthält, welche auf die Tabelle ORTE verweist, in der Orte, Postleitzahlen und Vorwahlen eingetragen werden. Die Spalte ORT_ID ist jedoch nicht als Foreign-Key deklariert, die entsprechende Zuweisung erfolgt erst im zugehörigen View.

Nun habe ich festgestellt, daß in View_ADRESSEN genau eine Adresse weniger angezeigt wird als in der Tabelle ADRESSEN. Wie das zustandekam, konnte ich mir leicht erklären, denn ich habe gestern den halben Tag damit verbracht, die Tabelle ORTE zu bereinigen, weil dort etliche Orte quasi doppelt vorhanden waren: gleiche Postleitzahl mit anderer Schreibweise des Ortes (z.B. München-Schwabing und München mit derselben PLZ). Ich habe also irgendwo vergessen, einer Adresse die verbliebene ORT_ID zuzuweisen (z.B. München-Schwabing gelöscht, aber die Adresse mit dieser ORT_ID nicht geändert), so daß diese eine Adresse nun eine ORT_ID aufweist, die in der Tabelle ORTE nicht mehr existiert. Wie finde ich diesen Record heraus, ohne händisch alle Tabellen durchgehen zu müssen?

Besten Dank für euer Interesse.

[Olli73]

Code:

select * from ADRESSEN where ORT_ID not in (select ORT_ID from ORTE)

(falls ich dein Problem richtig verstanden habe)

[Uwe Raabe]

Oder so:

Code:

select * 
from adressen a
left join orte b
on a.ort_id = b.<???>
where b.<???> is null

Heißt das ID-Feld in Orte auch ORT_ID?

[Uwe Raabe]

Für's nächste mal:

[Perlsau]

Zitat:

Zitat von Olli73 (Beitrag 1313868)

Code:

select * from ADRESSEN where ORT_ID not in (select ORT_ID from ORTE)

(falls ich dein Problem richtig verstanden habe)

Du hast mein Problem vollkommen richtig verstanden und die perfekte Lösung dafür präsentiert. :thumb:
Ich konnte den fehlerhaften Record finden und korrigieren.
Nun werden in der Originaltabelle genau so viele Records angezeigt wir im View. Herzlichen Dank dafür :love:

Zitat:

Zitat von Uwe Raabe (Beitrag 1313869)

Oder so:

Code:

select * 
from adressen a
left join orte b
on a.ort_id = b.<???>
where b.<???> is null

Dank auch dir :thumb:
Die Version von Olli empfinde ich jedoch als handlicher, weil sie kürzer ist (und nicht, weil sie früher da war).

Zitat:

Zitat von Uwe Raabe (Beitrag 1313869)

Heißt das ID-Feld in Orte auch ORT_ID?

Nein, ich habe Phantasie-Bezeichner gewählt, um das Problem so anschaulich wie möglich darzustellen: Tabellen und Spalten lauten bei mir anders. Dennoch war ich in der Lage, die gepostete Lösung erfolgreich auf mein Problem anzuwenden. Ich gehe sogar davon aus, daß ich diese Lösung auch in zukünftig auftretenden ähnlichen Fällen anzuwenden in der Lage sein werde. Aber dennoch danke für deine fürsorgliche Nachfrage :-D

Zitat:

Zitat von Uwe Raabe (Beitrag 1313870)

Für's nächste mal:

Danke auch dafür, das kann ich gut gebrauchen. :thumb:
Hab's mir gleich runtergeladen, ausgedruckt und an die Wand gepinnt.

[p80286]

Die "not in" Lösung stoßt aber eher an die Grenzen der DB (Begrenzung der Menge), darum wäre die Lösung von Uwe zu bevorzugen.

Gruß
K-H

[Perlsau]

Zitat:

Zitat von p80286 (Beitrag 1313912)

Die "not in" Lösung stoßt aber eher an die Grenzen der DB (Begrenzung der Menge), darum wäre die Lösung von Uwe zu bevorzugen.

Versteh ich jetzt nicht: welche Grenzen? Ich hab da ungefähr 2500 Datensätze in der Adresstabelle und ca. 1400 in der Orttabelle. Erstere wird allerhöchstens 50.000 Datensätze haben (mehr gibt's in dieser Branche nicht in DE), letztere vielleicht ... keine Ahnung, aber keine 20.000 schätze ich mal ... Schließlich hab ich das bis jetzt nur einmal benötigt, um in IbExpert im SQL-Editor den fehlerhaften Record zu finden. Das ging so schnell, ich hatte kaum Zeit zum Blinzeln :lol:
Also warum sollte ich mir da jetzt tiefere und noch weiter tiefergehende Gedanken machen müssen :?:

[jobo]

Zitat:

Zitat von Perlsau (Beitrag 1313914)

Zitat:

Zitat von p80286 (Beitrag 1313912)

Die "not in" Lösung stoßt aber eher an die Grenzen der DB (Begrenzung der Menge), darum wäre die Lösung von Uwe zu bevorzugen.

Versteh ich jetzt nicht: welche Grenzen?

Versteh es einfach als freundlichen Hinweis bzw. Warnung. Wie Deine konkrete Datensituation in Zahlen aussieht, kann ja niemand vorher wissen. Die Grenzen sind wie immer DB und Versionsabhängig.
Auf die Schnelle hab ich zu Firebird nichts konkretes außer diesem Post gefunden:
https://groups.yahoo.com/neo/groups/...s/topics/95414

Dabei ist nicht klar, ob die Limitierung nur für explizite Aufzählung oder auch für dynamische Selectrückgaben erfolgt.

Meine Verständnis ist:
(not) in .. für kleineren Abgleich (also adhoc, kleine Komfortabfragen)
table join .. für unlimitierten Massenabgleich (also für den Rest)

Wenn Du es genau für Deine Version wissen willst, musst Du wohl selbst danach suchen oder es ausprobieren.

[mkinzler]

Da rächt sich die Ansicht, dass man man aus Zeit-/Kostengründen beim Datenbankdesign auf die Deklaration der Constraints VWzüchten kann, da man diese ja im Programm berücksichtigt.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1313921)

VWzüchten

Bitte nicht mit Handy von Unterwegs auf der Autobahn posten, schon gar nicht, wenn es ein VW ist. Da geht nicht nur die Worterkennung schnell mal schief.
;)

Zitat:

Zitat von mkinzler (Beitrag 1313921)

Da rächt sich die Ansicht..

Naja, das wäre eigentlich die Hauptbotschaft des Threads, der sich originär um die Beseitigung der Folgen dreht!