Fehlerhaften ForeinKey finden

[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 von 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.

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
Also warum sollte ich mir da jetzt tiefere und noch weiter tiefergehende Gedanken machen müssen

[jobo]

Zitat von Perlsau:

Zitat von 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.

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 von mkinzler:

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 von mkinzler:

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!

[Perlsau]

Zitat von 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.

Oh, da bist du aber leicht im Irrtum: Selbstverständlich existiert ein eindeutiger Index Ortname-PLZ, so daß dieselbe Variante nicht doppelt vorkommen kann. Die Daten stammen allerdings aus einer Liste, die durch Selbstauskunft von Mitgliedern einer bestimmten Branche entstand – daher diese verschiedenen Schreibweisen für die Orte: Die meisten schreiben zwar ihre PLZ richtig, hängen dann aber ihren Ortsteilbezeichner noch hintendran oder verwenden nur den Ortsteil, z.B. 76227 Durlach oder 76227 Karlsruhe-Durlach oder 76227 Karlsruhe/Durlach statt einfach 76227 Karlsruhe. Ähnliches haben wir hier bei den Telefon-, Fax- und Handynummern. Hier halte ich mich an eine Vorwahlenliste, mit deren Hilfe ich die Vorwahlen abtrenne und mit der Vorwahl, die der PLZ zugeordnet ist, vergleiche. Records, die hier Diskrepanzen aufweisen, werden markiert und müssen später einzeln verifiziert werden (Branchenbuch, Gelbe Seiten etc.).

Ist also nicht immer nur die schon fast sprichwörtliche Dummheit oder Unerfahrenheit des Programmierers, die zu Datenbankfehlern führen kann ...

[Olli73]

Zitat von Perlsau:

Zitat von 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.

Oh, da bist du aber leicht im Irrtum: Selbstverständlich existiert ein eindeutiger Index Ortname-PLZ, so daß dieselbe Variante nicht doppelt vorkommen kann.

Da war wohl was anderes gemeint: Du kannst in der Datenbank den Foreign Key / Constraint so hinterlegen, dass die DB es nicht zugelassen hätte, einen Ort zu Löschen, solange dieser noch in einem Adress-Datensatz verwendet wird. Der "fehlerhafte Datensatz" wäre dir also schon beim Lösch-Versuch der "überflüssigen" Orte aufgefallen und nicht erst später. Es wäre also nie zu einer Inkonsistenz gekommen.

Als weiterer Hinweis: Ist die ORT_ID in der Tabelle Adressen als "NOT NULL" (also als Pflichtfeld) deklariert? Falls nicht, solltest du einen "left outer join" (ähnlich wie in #3) in deine View einbauen, damit dort auch Adressen auftauchen, für die kein Ort angegeben wurde.

[Perlsau]

Ach, jetzt versteh ich: Klar, die Ort-Id in der Adresstabelle als ForeignKey zu kennzeichnen ist sinnvoll. Hab das soeben nachgeholt:

Code:

alter table ADRESSEN
add constraint FK_ADRESSEN_ORTE
foreign key (ORT) references ORTE(ID_ORTE)
using desc index IX_ADRESSEN_ORTE

Zitat von Olli73:

Als weiterer Hinweis: Ist die ORT_ID in der Tabelle Adressen als "NOT NULL" (also als Pflichtfeld) deklariert?

Selbstverständlich: PK ist bei mir in der Regel immer NOT NULL, weil ich den mit dem AutoInc-Tool von IbExpert erstelle; der macht das automatisch.