Verknüpfte Datensätze löschen

[Smart]

Hi,

ich habe 3 Tabellen, die durch Primär- und Fremdschlüssel miteinander verbunden sind. Gibt es einen Weg, alle verbundenen Datensätze in einem Rutsch zu löschen? Ich meine, bei Löschung eines Datensatzes mit dem Primärschlüssel aus der 1. Tabelle sollen die verknüpften Datensätze durch Fremdschlüssel in Tabelle 2 und 3 auch automatisch gelöscht werden. Oder muss man diese manuell löschen.

Danke im Voraus

[Ralf Jansen]

Deine Datenbank sollte Cascade Deletes unterstützen. Ob es was eingebautes in ADO.Net gibt ist mir gerade nicht bewußt.

Ich würde von solchen Automatismen aber eh abraten. Habe zuviele Anwendungen gesehen die ihre Datenbank großflächig leergeräumt haben wegen unerwartetem Verhalten beim automatischen mitlöschen Beim löschen würde ich immer dazu raten das explizit auszuprogrammieren damit es auch wirklich knallt wenn da was schief läuft.

[Smart]

Hallo Ralf,

vielen Dank für deine Antwort.
Ich arbeite gerade mir VS2010. Ich habe mir gedacht, vielleicht hat man unter VisualStudio eine automatisierte Möglichkeit, dies zu tun. Was empfehlst du dann am besten für solche tätigkeiten, wie Löschen oder Updates, bei denen mehrere Datensätze aus unterschiedlichen Tabellen beteiligt sind?

Gruß

[defo]

Was empfehlst du dann am besten für solche tätigkeiten, wie Löschen oder Updates, bei denen mehrere Datensätze aus unterschiedlichen Tabellen beteiligt sind?

Wie Ralf schon sagte, explizit ausprogrammieren. Ich würde das allerdings auf dem DB-Server machen, niemals auf dem/irgendeinem Client.
In Frage kommen Stored Prozedures / Trigger.
In Einzelfällen ggF. auch Cascade Deletes, wenn ganz sicher ist, dass nicht versehentlich zuviel gelöscht wird.

Vielleicht bietet VS2010 da via ADO auch Möglichkeiten, die würde ich aber nicht nutzen, ich kenne sie sicherheitshalber gar nicht.

Noch eine fachliche Anmerkung:
Je nach Anwendungsfall muss/darf gar nicht ohne weiteres gelöscht werden. Sobald es um Business Prozesse mit einem Kunden und zugehörige Daten geht, kann man eigentlich nur Daten löschen, die absolut falsch sind und noch nicht Grundlage für weitere Prozesse waren.

[Ralf Jansen]

Was empfehlst du dann am besten für solche tätigkeiten, wie Löschen oder Updates, bei denen mehrere Datensätze aus unterschiedlichen Tabellen beteiligt sind?

Transaktion aufmachen. Daten in Tabelle 1 löschen dann Daten in Tabelle 2 löschen etc. Transaktion commiten oder rollbacken. Explizit eben mit voller Kontrolle

Wie Ralf schon sagte, explizit ausprogrammieren. Ich würde das allerdings auf dem DB-Server machen, niemals auf dem/irgendeinem Client.

Eigentlich nicht verkehrt das zu zentralisieren. Aber die meisten DB Zugriffsframeworks wie eben auch ADO.Net die mit lokalen unabhängigen Datenmengen arbeiten haben da ein Problem. Die bekommen nicht mit wenn etwas parallel auf dem DB Server passiert. Das artet immer in riesige Synchronisierungsaktionen aus um lokal dann auch denn richtigen Stand zu haben. Heißt auch der Client muß eigentlich Wissen was die Datenbank da genau tut um die richtige Synchronisierung anzustossen. Jetztz habe ich plötzlich 2 Beteiligte die genau aufeinander abgestimmt sein müssen was schlimmer ist als diese Logik gleich nur außerhalb der DB zu haben und die DB nur als dummen Persistierer zu verwenden. Denn sobald ich irgendwas anpassen muß ist die Wahrscheinlichkeit dann groß gleich an 2 Stellen, eben Client und Datenbank, drehen zu müssen. Lange Rede kurzer Sinn. Sobald Frameworks ins Spiel kommen die ihr eigenes spezielles Verhalten aufdrücken bin ich anderer Meinung als du Mann muß sich drauf einlassen und nicht dagegen arbeiten (Oder auf dieses Framework verzichten)

[Wernfried]

Ich würde von solchen Automatismen aber eh abraten. Habe zuviele Anwendungen gesehen die ihre Datenbank großflächig leergeräumt haben wegen unerwartetem Verhalten beim automatischen mitlöschen Beim löschen würde ich immer dazu raten das explizit auszuprogrammieren damit es auch wirklich knallt wenn da was schief läuft.

Das halte ich für Ansichtssache, ich habe schon zuviele Anwendungen gesehen die vor inkonsistenten Daten nur so strotzen. Deshalb bin ich eher ein Fan von Cascade Deletes, natürlich sollte man sie nicht blind überall einsezten.

Gruss

[Ralf Jansen]

Das halte ich für Ansichtssache, ich habe schon zuviele Anwendungen gesehen die vor inkonsistenten Daten nur so strotzen.

Die Alternative zu Cascade Deletes ist sicher nicht referenziele Integrität gleich ganz wegzulassen.

Deshalb bin ich eher ein Fan von Cascade Deletes, natürlich sollte man sie nicht blind überall einsezten.

Unter der Prämisse das jeder so vernünftig ist über die eingesetzten Mittel richtig nachzudenken und dann ein Feature gezielt einzusetzen (mit Funktionstest und allem drum und dran) gabe es sicher keine Kritik an Cascade Deletes von mir
Es läuft leider als zu oft anders.

[connysoft]

hi,
ich kenne das Promlem. Ich habe eine Desktopanwendung zur Produktpflege programmiert. Das tatsächliche löschen von Daten sollte man nicht dem normalen User überlassen. Deshalb mein Vorschlag, den Parentdatensatz um ein delete-Flag erweitern. So kann erst mal nichts so schnell verschwinden. Das tatsächliche Löschen sollte dann ein entsprechender Verantwortungsträger in einem sicheren Scenario vornehmen. Wenn es nur um den reinen Mechanismus geht, finde ich cascade delete recht bequem. In ADO.NET ist das übrigens recht einfach, wenn man vom Parentdatensatz ausgeht und dann alle Childdatensätze (GetChildRows) mit row.delete löscht.