Verwaiste Einträge finden
-
Ich habe drei Tabellen:
Tabelle Film
int id
varchar titel
...Tabelle Schauspieler
int id
varchar name
...Tabelle Filmschauspieler
int idFilm
int idSchauspielerJetzt sind in der Tabelle Film mehrere Filme gelöscht worden, die Tabelle Schauspieler blieb aber versehendlich unverändert und enthält deshalb verwaiste Einträge.
Meine Frage: mit welchem SQL-Kommando finde ich diese verwaisten Einträge?
-
SELECT ... FROM ... WHERE id NOT IN (...)
-
indem du die tabellen richtig anlegst
CREATE TABLE `filmschauspieler` ( `idFilm` INT NOT NULL REFERENCES film.id ON DELETE CASCADE, `idSchauspieler` INT NOT NULL REFERENCES schauspieler.id ON DELETE CASCADE );
wenn also Film oder Schauspieler gelöscht wird, wird auch die entsprechende Verbindung entfernt. Die DB-Engine muss das natürlich unterstützen
wobei ich mich grad frage, warum du Schauspieler entfernen willst, wenn der Film weg ist. Schließlich kann er auch in anderen Filmen mitspielen
-
zwutz schrieb:
wobei ich mich grad frage, warum du Schauspieler entfernen willst, wenn der Film weg ist. Schließlich kann er auch in anderen Filmen mitspielen
Schauspieler speichern, die von keinem anderen Film referenziert werden? Hm ...
-
schmidt-webdesign.net schrieb:
zwutz schrieb:
wobei ich mich grad frage, warum du Schauspieler entfernen willst, wenn der Film weg ist. Schließlich kann er auch in anderen Filmen mitspielen
Schauspieler speichern, die von keinem anderen Film referenziert werden? Hm ...
Wieso sollte er Schauspieler löschen, nur weil diese im Moment von keinem Film referenziert werden? Nur damit er sie später evtl. neu anlegen muss?
-
@zwutz:
Damit kann er auch nur sicherstellen, dass die Verbindung entfernt wird, wenn ein primäres Objekt (Schauspieler oder Film) entfernt wird. Was IMO gar nicht optimal ist - ich würde das Löschen eines Schauspielers nicht erlauben, so lange es noch Filme gibt, in denen er mitspielt. Aber egal.Was damit nicht automatisch passiert, ist dass der Schauspieler gelöscht wird, wenn es keine Verweise mehr auf ihn gibt. D.h. es verhindert das von ihm beschriebene "Problem" nicht (mal egal ob man es überhaupt als Problem sehen will oder nicht).
-
hustbaer schrieb:
SELECT ... FROM ... WHERE id NOT IN (...)
Hallo hustbaer,
kannst Du das genauer schreiben? Ich bin noch Anfänger mit Datenbanken.
Danke!
An die anderen: ich möchte alle überflüssigen Einträge aus meiner DB entdernen, weil sie nicht mehr benötigt werden.
-
hustbaer schrieb:
SELECT ... FROM ... WHERE id NOT IN (...)
Nach einigen schlechten Erfahrungen, und Hinweisen von mehr als einen DB-Admin, würde ich tendenziell immer NOT IN mit NOT EXISTS vergleichen, was schneller ist (Nach meiner bisherigen Erfahrung tendenziell letzteres, kann aber am DB-System hängen).
-
Mrs. DB schrieb:
hustbaer schrieb:
SELECT ... FROM ... WHERE id NOT IN (...)
Hallo hustbaer,
kannst Du das genauer schreiben? Ich bin noch Anfänger mit Datenbanken.
Danke!
An die anderen: ich möchte alle überflüssigen Einträge aus meiner DB entdernen, weil sie nicht mehr benötigt werden.
Ist doch ganz einfach:
SELECT id FROM Schauspieler WHERE (id NOT IN (SELECT idSchauspieler FROM Filmschauspieler))
-
schmidt-webdesign.net schrieb:
Ist doch ganz einfach:
SELECT id FROM Schauspieler WHERE (id NOT IN (SELECT idSchauspieler FROM Filmschauspieler))
Wobei ich mich frage, warum hier die doppelten Klammerpaare nötig sein sollen..
SELECT id FROM Schauspieler WHERE id NOT IN ( SELECT idSchauspieler FROM Filmschauspieler)
oder
SELECT s.id FROM Schauspieler s WHERE s.id NOT EXISTS ( SELECT fs.idSchauspieler FROM Filmschauspieler fs WHERE s.id = fs.idSchauspieler)
-
asc schrieb:
hustbaer schrieb:
SELECT ... FROM ... WHERE id NOT IN (...)
Nach einigen schlechten Erfahrungen, und Hinweisen von mehr als einen DB-Admin, würde ich tendenziell immer NOT IN mit NOT EXISTS vergleichen, was schneller ist (Nach meiner bisherigen Erfahrung tendenziell letzteres, kann aber am DB-System hängen).
Mag sein dass es mit bestimmten Datenbanken da Unterschiede gibt.
MSSQL ab 2005 (die einzige DB mit der ich viel Erfahrung habe) ist es egal, kommt der selbe Execution-Plan 'bei raus.
Vergleichen was schneller ist ist natürlich nie verkehrt.
Und wo wir gerade dabei sind: meinst du es macht Sinn auch noch die
LEFT JOIN
Variante zu vergleichen?SELECT s.id FROM Schauspieler AS s LEFT JOIN Filmschauspieler AS fs ON fs.idSchauspieler = s.id WHERE fs.idSchauspieler IS NULL