AW: Fehlerhaften ForeinKey finden
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Ist also nicht immer nur die schon fast sprichwörtliche Dummheit oder Unerfahrenheit des Programmierers, die zu Datenbankfehlern führen kann ... |
AW: Fehlerhaften ForeinKey finden
Zitat:
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. |
AW: Fehlerhaften ForeinKey finden
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:
|
AW: Fehlerhaften ForeinKey finden
Zitat:
|
AW: Fehlerhaften ForeinKey finden
Da oben steht doch schwarz auf weiß: ALTER TABLE ADRESSEN
Wie kommst du jetzt drauf, ich hätte die Tabelle Orte geändert? Nach dem oben geposteten SQL-Script habe ich nun einen Foreign-Key in der Tabelle Adressen, der auf den den PK der Tabelle ORTE zeigt. Wo siehst du da jetzt ein Problem? |
AW: Fehlerhaften ForeinKey finden
Genau das war doch die Frage: ist es möglich, dass das Foreign-Key-Feld auf Orte in der Adress-Tabelle NULL enthält? Übrigens sind in allen mir bekannten DBMs PK immer NOT NULL und UNIQUE, ohne dass man das explizit angeben müsste. Ohne das könnten sie ihren Zweck ja auch kaum erfüllen.
|
AW: Fehlerhaften ForeinKey finden
Zitat:
|
AW: Fehlerhaften ForeinKey finden
Zitat:
Code:
bei den foreign keys. Lieferant löschen => auch Artikel sind weg, sofern die einen foreign Key auf die Lieferanten-ID haben.
on delete cascade
Jetzt gehts aber irgendwann ums Geld : da sind nämlich noch 2 unbezahlte Rechnungen mit den 10 Artikeln, die ich ja soeben gelöscht habe wegen des Lieferanten. Schreib jetzt mal davon eine Mahnung. Die würde ähnlich aussehen, wie Deine Liste. Wegen der gelöschten Artikel stehen keine Rechnungspositionen auf der Rechnung, eventuell aber ein Endbetrag, weil der mit dem gelöschten Kram prinzipiell nichts zu tun hat. Also, das ganze ist auch ein Rattenschwanz bei dem man verdammt aufpassen muss. Um die verschwundenen Rechnungs-Artikel eventuell noch irgendwie sichtbar zu halten gibts ja noch mehr :
Code:
z.B. oder
on delete set null
Code:
Unbedingt ansehen ! Einfach löschen geht jedenfalls nicht. Bei abhängigen Tabellen komplett auf Foreign Keys zu verzichten, tsts. 8-)
on update cascade
|
AW: Fehlerhaften ForeinKey finden
Ihr geht bei euren Erklärungen aus meiner Sicht etwas zu sehr in die (SQL)Details der Realisierung.
-> Hier geht es doch schlicht um die (derzeit dort wohl fehlende) "Referenzielle Integrität", was für mich die Hauptaufgabe eines DBMS ist, denn Daten in Tabellen speichern&abfragen, das kann man notfalls auch per CSV Dateien. Ein "on delete cascade" wird es in meinen Anwendungen nicht geben. Dort sollen die Exceptions fliegen, wenn wer was zu löschen versucht, was noch anderswo in Benutzung ist. Wenn überhaupt mache ich das per Triggerfunktion, wo dann StepByStep mit voller Absicht alles einzeln gelöscht wird/werden muss. Ein "on update cascade" ist bei mir das einzige, was ich "notfalls" im SingeUserMode für Admins zulasse. Es passiert im Alltag, das mal Artikelnummern "auf die schnelle" von irgendwem angelegt werden, aber derjenige übersieht das es eigentlich eine Struktur gibt, wo sagen wir 1xxxyyyyyy doch was anderes ist wie 2xxxyyyyyy... Anwender sind manchmal kreativ beim einbauen und erfinden von eigenen Zusatzregeln... um sowas dann "in einem Rutsch" zu ändern, so das es sich automatisch auf die gesamte DB auswirkt, egal wo etwas mit diesem Datensatz zu tun hat, genau dafür ist dann ein "on update cascade" brauchbar, aber nicht als Standard. Per Default lasse ich das DBMS eine Execption schmeißen, wenn jemand versucht "Verknüpfungsdaten" einfach so zu ändern. Das mal als einfache "Erklärung" ohne viel DBMS/SQL Speak, denn ich gebe zu, das ich sowas per Datenbankdesigner-Software und nicht per manuellem SQL Script erstelle und konfiguriere... Hauptsache ich weiß, warum ich es tue:) (ps: so Sachen wie unterschiedliche Schreibweisen funktionieren bei mir mit zusätzlichen Alias-Tabellen in diesem Fall z.B. über PLZ+Vorwahl als Zusatzschlüssel) |
AW: Fehlerhaften ForeinKey finden
Zitat:
Wie oben bereits berichtet, entstanden durch das Einlesen von "unordentlichen" Listen Orte mit unterschiedlichen Schreibweisen, aber gleichen Postleitzahlen. Das ließe sich nur vermeiden, wenn man die Listen vor dem Einlesen manuell am Editor durchforstet, und das wäre ja wohl der Gipfel der Zeitverschwendung ... und der zermürbenden Arbeit ... Diese Listen müssen von mir nur einmal eingelesen werden, der Anwender bearbeitet die Datenbank-Einträge dann per Hand ... so viele neue Firmen werden in dieser Branche nicht ständig gegründet und beim Anwender angemeldet, daß er das nicht manuell bewältigen könnte. So kann er dann prüfen, ob der Eintrag korrekt ist, die Firmendaten stimmen usw. Die Listen, die ich einmalig einlese und oberflächlich verifiziere, sind dagegen in einem Zeitraum von zig Jahren entstanden. Zitat:
Daß das Thema hier trotz bereits erfolgter Problemlösung ständig weitere Kommentare erhält, die meinem Empfinden nach einer teilweise fragwürdigen Intention geschuldet sind, hat mich ein wenig verwundert ... nur ein wenig deshalb, weil das hier im Grunde täglich zu beobachten ist. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz