Wann / Warum wird Cascading in SQL Server verwendet?

149

Unter welchen Umständen sollte beim Einrichten von Fremdschlüsseln in SQL Server diese beim Löschen oder Aktualisieren kaskadiert werden, und was ist der Grund dafür?

Dies gilt wahrscheinlich auch für andere Datenbanken.

Ich suche vor allem nach konkreten Beispielen für jedes Szenario, vorzugsweise von jemandem, der sie erfolgreich eingesetzt hat.

Joel Coehoorn
quelle
4
Diese Frage scheint nicht eng mit SQL Server verbunden zu sein und ähnelt eher einer theoretischen, allgemeinen Frage. Es wäre für die Community nützlicher, wenn Sie das sql-serverTag entfernen .
Clapas
4
@clapas Ehrlich gesagt, wenn ich es heute fragen würde, wäre es nicht zum Thema. Wenn nicht für die hohen Ansichten / Stimmen, die anzeigen, dass es Wert für die Gemeinschaft hat, würde ich es einfach löschen.
Joel Coehoorn
6
@JoelCoehoorn - Offensichtlich haben diese Art von Fragen einen Wert. Dieser Wert geht im Laufe der Zeit nicht verloren. Die Frage in meinem Kopf ist, wie viel Wert wir verlieren, wenn wir solche Fragen heute nicht zulassen.
P.Brian.Mackey
2
@ P.Brian.Mackey Hier, hier! Einige der besten Fragen / Antworten, die ich gesehen habe, sind diejenigen, die als nicht thematisch abgestimmt oder gemalt wurden ... aber Sie können an der RIESIGEN Anzahl von Stimmen erkennen, dass viele genau die gleiche Frage hatten!
Anthony Griggs
Kaskadierende Aktionen erfordern serialisierbare Sperren.
Mitch Wheat

Antworten:

126

Zusammenfassung dessen, was ich bisher gesehen habe:

  • Manche Leute mögen es überhaupt nicht, zu kaskadieren.

Kaskade löschen

  • Kaskadenlöschung kann sinnvoll sein, wenn die Semantik der Beziehung eine exklusive Beschreibung "Teil " enthält. Ein OrderLine-Datensatz ist beispielsweise Teil seiner übergeordneten Bestellung, und OrderLines werden niemals von mehreren Bestellungen gemeinsam genutzt. Wenn der Auftrag verschwinden würde, sollte auch die Auftragszeile verschwinden, und eine Zeile ohne Auftrag wäre ein Problem.
  • Das kanonische Beispiel für Cascade Delete ist SomeObject und SomeObjectItems, bei denen es keinen Sinn macht, dass ein Elementdatensatz jemals ohne einen entsprechenden Hauptdatensatz existiert.
  • Sie sollten Cascade Delete nicht verwenden, wenn Sie den Verlauf beibehalten oder einen "weichen / logischen Löschvorgang" verwenden, bei dem Sie nur eine gelöschte Bitspalte auf 1 / true setzen.

Kaskaden-Update

  • Cascade Update kann sinnvoll sein, wenn Sie einen echten Schlüssel anstelle eines Ersatzschlüssels (Identitäts- / Autoincrement-Spalte) für mehrere Tabellen verwenden.
  • Das kanonische Beispiel für Cascade Update ist, wenn Sie einen veränderlichen Fremdschlüssel haben, beispielsweise einen Benutzernamen, der geändert werden kann.
  • Sie sollten nicht Cascade - Update mit den Tasten verwenden , die Identität / Autoinkrement - Spalten sind.
  • Cascade Update wird am besten in Verbindung mit einer eindeutigen Einschränkung verwendet.

Wann wird Cascading verwendet?

  • Möglicherweise möchten Sie vom Benutzer eine besonders starke Bestätigung zurückerhalten, bevor Sie eine Operation kaskadieren lassen. Dies hängt jedoch von Ihrer Anwendung ab.
  • Kaskadierung kann zu Problemen führen, wenn Sie Ihre Fremdschlüssel falsch eingerichtet haben. Aber du solltest in Ordnung sein, wenn du das richtig machst.
  • Es ist nicht ratsam, Kaskadierung zu verwenden, bevor Sie es gründlich verstanden haben. Es ist jedoch eine nützliche Funktion und es lohnt sich daher, sich die Zeit zum Verstehen zu nehmen.
Joel Coehoorn
quelle
3
Beachten Sie, dass Kaskadenaktualisierungen auch häufig verwendet werden, wenn die "sogenannten" natürlichen Schlüssel nicht diese wirklich effektiven eindeutigen Schlüssel zu sein scheinen. Tatsächlich bin ich davon überzeugt, dass Kaskadenaktualisierungen nur bei schlecht normalisierten Datenbankmodellen erforderlich sind und ein offenes Tor zu unordentlichen Tabellen und unordentlichem Code darstellen.
Philippe Grondier
1
Ihnen fehlt ein wichtiger Punkt: Kaskadierung kann zu großen Leistungsproblemen führen, wenn viele untergeordnete Datensätze vorhanden sind.
HLGEM
13
@HLGEM - Ich sehe die Relevanz nicht. Wenn eine Kaskadenoperation eine Verlangsamung verursacht, würde der entsprechende manuelle Prozess entweder dieselbe Verlangsamung verursachen oder nicht richtig geschützt sein, falls die Transaktion zurückgesetzt werden muss.
Joel Coehoorn
3
Warum ist es wichtig, ob eine IDENTITY- oder eine Auto-Inkrement-Spalte kaskadiert wird? Ich kann sehen , warum es nicht wäre notwendig , weil Sie nicht diese (willkürlichen) Werte ändern müssen , sollen, aber wenn einer von ihnen tut ändern, zumindest die referentielle Integrität wäre intakt.
Kenny Evitt
3
10 Kugeln? Nun wissen wir, dass Joel keinen Revolver abfeuert.
Neil N
68

Fremdschlüssel sind der beste Weg, um die referenzielle Integrität einer Datenbank sicherzustellen. Das Vermeiden von Kaskaden aufgrund von Magie ist wie das Schreiben von allem in Assembly, weil Sie der Magie hinter Compilern nicht vertrauen.

Was schlecht ist, ist die falsche Verwendung von Fremdschlüsseln, wie sie beispielsweise rückwärts erstellt werden.

Das Beispiel von Juan Manuel ist das kanonische Beispiel. Wenn Sie Code verwenden, besteht eine viel größere Wahrscheinlichkeit, dass falsche DocumentItems in der Datenbank verbleiben, die Sie beißen.

Kaskadierende Aktualisierungen sind beispielsweise nützlich, wenn Sie Verweise auf die Daten haben, die sich ändern können. Angenommen, ein Primärschlüssel einer Benutzertabelle ist die Kombination aus Name und Nachname. Dann möchten Sie, dass Änderungen in dieser Kombination überall dort weitergegeben werden, wo sie referenziert werden.

@Aidan, Diese Klarheit, auf die Sie sich beziehen, ist mit hohen Kosten verbunden. Die Wahrscheinlichkeit, dass falsche Daten in Ihrer Datenbank verbleiben, ist nicht gering . Für mich ist es normalerweise nur mangelnde Vertrautheit mit der DB und Unfähigkeit, herauszufinden, welche FKs vorhanden sind, bevor ich mit der DB zusammenarbeite, die diese Angst fördern. Entweder das oder ständiger Missbrauch der Kaskade, wenn die Entitäten konzeptionell nicht miteinander verbunden waren oder wenn Sie die Geschichte bewahren müssen.

Vinko Vrsalovic
quelle
7
Die Verwendung eines solchen "natürlichen" Primärschlüssels ist in erster Linie eine wirklich schlechte Idee.
Nick Johnson
4
RE: Kommentar an Aidan gerichtet. Nein, das Weglassen von CASCADE auf einem FK erhöht nicht die Wahrscheinlichkeit, falsche Daten zu hinterlassen. Dies verringert die Wahrscheinlichkeit, dass mehr Daten von einem Befehl betroffen sind als erwartet, und erhöht den Code. Wenn Sie FKs ganz weglassen, besteht die Möglichkeit von falschen Daten.
Shannon Severance
5
Nachdem ich mindestens zweimal in meiner Karriere die geschäftsbedrohlichen Folgen einer missverstandenen Kaskadenlöschung gesehen habe, bin ich sehr abgeneigt, sie in allen Fällen außer in den eindeutigsten Fällen selbst zu verwenden. In beiden Fällen wurden Daten aufgrund einer Kaskade gelöscht, die eigentlich hätte beibehalten werden sollen, aber nicht - und die fehlte - wurde erst erkannt, als der normale Sicherungszyklus die Möglichkeit einer einfachen Wiederherstellung verloren hatte. Vinko ist aus rein logischer Sicht richtig, aber in der realen Welt setzt die Verwendung von Kaskaden einen der menschlichen Fehlbarkeit und unvorhergesehenen Konsequenzen mehr aus, als ich möchte.
Cruachan
1
Ich habe tatsächlich Systeme codiert, in denen eine Verwaltungsentscheidung getroffen wurde, dass die Benutzer alle untergeordneten Elemente in einem Master-Detail explizit löschen müssen, bevor sie den Master löschen können, um den Benutzer zum Nachdenken zu zwingen. Kaskaden nicht zu verwenden, wenn dies logischerweise möglich ist, ist eine ähnliche Art von Brandschutz.
Cruachan
6
@Cruachan: Die Regel ist meiner Ansicht nach einfach. Wenn die Daten nicht so stark miteinander verbunden sind, dass sie ohne die übergeordneten Daten unbrauchbar sind, ist eine Kaskadenbeziehung nicht gerechtfertigt. Dies habe ich versucht, im letzten Satz meiner Antwort anzusprechen.
Vinko Vrsalovic
17

Ich verwende niemals kaskadierende Löschvorgänge.

Wenn ich möchte, dass etwas aus der Datenbank entfernt wird, möchte ich der Datenbank explizit mitteilen, was ich herausnehmen möchte.

Natürlich sind sie eine Funktion, die in der Datenbank verfügbar ist, und es kann vorkommen, dass sie in Ordnung sind. Wenn Sie beispielsweise eine 'order'-Tabelle und eine' orderItem'-Tabelle haben, möchten Sie die Elemente möglicherweise löschen, wenn Sie eine löschen Auftrag.

Ich mag die Klarheit, die ich bekomme, wenn ich es in Code (oder einer gespeicherten Prozedur) mache, anstatt dass 'Magie' passiert.

Aus dem gleichen Grund bin ich auch kein Fan von Triggern.

Wenn Sie eine 'Bestellung' löschen, erhalten Sie den Bericht '1 Zeile betroffen' zurück, selbst wenn durch das kaskadierte Löschen 50 'orderItem' entfernt wurden.

Loofer
quelle
34
Warum nicht auch Primärschlüssel loswerden? Sie erhalten die Klarheit, eindeutige Werte in Ihrem Code sicherzustellen.
MusiGenesis
4
@MusiGenesis, Aidan befürwortete nicht das Entfernen der FK. Der FK schützt die Daten weiterhin, aber ohne CASCADE ON ... passiert keine unerwartete Magie.
Shannon Severance
7
@Vinko: Löschen und Aktualisieren haben eine gut definierte Standardsemantik. Wenn Sie das Verhalten über eine Kaskade oder einen Auslöser ändern, um mehr Arbeit zu erledigen, besteht die Möglichkeit, dass mehr getan wurde als beabsichtigt. Nein, ich arbeite nicht ohne Tests und ja, meine Datenbanken sind dokumentiert. Aber erinnere ich mich beim Schreiben von Code an jede Dokumentation? Wenn ich eine Semantik auf höherer Ebene möchte, wie z. B. Löschen von Eltern und Kindern, schreibe ich und verwende dazu einen SP.
Shannon Severance
3
@ Vinko. Das Problem der Magie liegt nicht bei kompetenten Entwicklern oder Datenbankadministratoren, sondern bei Joe Interen, der 5 Jahre später eine „einfache“ Wartungsaufgabe erhalten hat, wenn der Datenbankadministrator im Urlaub ist, und der dann Unternehmensdaten vermasselt, ohne dass es jemand merkt. Kaskaden haben ihren Platz, aber es ist wichtig, die vollständigen Umstände, einschließlich menschlicher Faktoren, zu berücksichtigen, bevor sie eingesetzt werden.
Cruachan
5
@ Vinko: Warum SPs nach Luft schnappen? SPs sind trotzig der richtige Weg, wenn die Datenbank ein kritisches Unternehmensgut ist. Es gibt ein starkes Argument für die Art der Umstände, über die gesprochen wurde, um alle Datenzugriffe auf SPs oder zumindest alle außer Select zu beschränken. Siehe meine Antwort unter stackoverflow.com/questions/1171769/…
Cruachan
13

Ich arbeite viel mit kaskadierenden Löschvorgängen.

Es fühlt sich gut an zu wissen, wer gegen die Datenbank arbeitet, darf niemals unerwünschte Daten hinterlassen. Wenn Abhängigkeiten zunehmen, ändere ich einfach die Einschränkungen im Diagramm in Management Studio und muss weder sp noch Datenzugriffe anpassen.

Das heißt, ich habe 1 Problem mit kaskadierenden Löschvorgängen und das sind Zirkelverweise. Dies führt häufig zu Teilen der Datenbank, die keine kaskadierenden Löschvorgänge aufweisen.

Mathias F.
quelle
1
Ich weiß, dass dies sehr alt ist, aber +1 für die Erwähnung des Zirkelreferenzproblems mit CASCADE DELETE.
Code Maverick
2
Verzeihen Sie eine Noob-Frage: Was passiert eigentlich, wenn Sie einen Zirkelverweis erhalten?
Tim Lovell-Smith
10

Ich mache viel Datenbankarbeit und finde Kaskadenlöschungen selten nützlich. Das einzige Mal, dass ich sie effektiv verwendet habe, befindet sich in einer Berichtsdatenbank, die durch einen nächtlichen Job aktualisiert wird. Ich stelle sicher, dass alle geänderten Daten korrekt importiert werden, indem ich alle Datensätze der obersten Ebene lösche, die sich seit dem letzten Import geändert haben, und dann die geänderten Datensätze und alles, was damit zusammenhängt, erneut importiere. Es erspart mir das Schreiben vieler komplizierter Löschvorgänge, die von unten nach oben in meiner Datenbank angezeigt werden.

Ich halte Kaskadenlöschungen nicht für so schlimm wie Trigger, da sie nur Daten löschen. Trigger können alle möglichen bösen Dinge enthalten.

Im Allgemeinen vermeide ich echte Löschvorgänge insgesamt und verwende stattdessen logische Löschvorgänge (dh eine Bitspalte namens isDeleted, die auf true gesetzt wird).

Martynnw
quelle
2
Du hast mich neugierig gemacht, mehr zu lernen. Warum bevorzugen Sie logische Löschungen? Haben die Daten, mit denen Sie arbeiten, etwas damit zu tun?
Tim Lovell-Smith
9

Ein Beispiel ist, wenn Sie Abhängigkeiten zwischen Entitäten haben ... dh: Dokument -> DocumentItems (wenn Sie Document löschen, haben DocumentItems keinen Grund zu existieren)

Juan
quelle
5

Verwenden Sie Kaskadenlöschung, wenn der Datensatz mit der FK entfernt werden soll, wenn der verweisende PK-Datensatz entfernt wurde. Mit anderen Worten, wenn der Datensatz ohne den referenzierenden Datensatz bedeutungslos ist.

Ich finde das Löschen von Kaskaden nützlich, um sicherzustellen, dass tote Referenzen standardmäßig entfernt werden, anstatt Null-Ausnahmen zu verursachen.

Testmuster
quelle
5

EIN Kaskade löschen:

Wenn Zeilen in der untergeordneten Tabelle gelöscht werden sollen Wenn die entsprechende Zeile in der übergeordneten Tabelle gelöscht wird .

Wenn das Löschen in der Kaskade nicht verwendet wird, wird ein Fehler für die referenzielle Integrität ausgelöst .

ON Update Cascade:

Wenn Sie Änderung der Primärschlüssel in aktualisiert werden Fremdschlüssel

Durai Amuthan.H
quelle
5

Ich habe von Datenbankadministratoren und / oder "Unternehmensrichtlinien" gehört, die die Verwendung von "On Delete Cascade" (und anderen) nur aufgrund schlechter Erfahrungen in der Vergangenheit verbieten. In einem Fall schrieb ein Mann drei Auslöser, die sich gegenseitig anriefen. Drei Tage, um sich zu erholen, führten zu einem völligen Verbot von Auslösern, alles aufgrund der Handlungen eines Idjits.

Natürlich werden manchmal Trigger anstelle von "On Delete Cascade" benötigt, beispielsweise wenn einige untergeordnete Daten beibehalten werden müssen. In anderen Fällen ist es jedoch durchaus gültig, die Kaskadenmethode On Delete zu verwenden. Ein wesentlicher Vorteil der "On Delete-Kaskade" besteht darin, dass ALLE Kinder erfasst werden. Eine benutzerdefinierte geschriebene Trigger- / Speicherprozedur funktioniert möglicherweise nicht, wenn sie nicht korrekt codiert ist.

Ich glaube, der Entwickler sollte die Entscheidung treffen dürfen, basierend auf der Entwicklung und den Angaben in der Spezifikation. Ein Teppichverbot aufgrund einer schlechten Erfahrung sollte nicht das Kriterium sein. Der Denkprozess "Niemals benutzen" ist bestenfalls drakonisch. Jedes Mal muss eine Entscheidung getroffen und Änderungen vorgenommen werden, wenn sich das Geschäftsmodell ändert.

Geht es nicht um Entwicklung?

BrianBurkill
quelle
Ich glaube nicht , es löschen würde alles ... meinen Sie das Feature tatsächlich tut , was sie sagt , es tut? ...
Joel Coehoorn
3

Ein Grund für das Löschen einer Kaskade (anstatt dies im Code zu tun) ist die Verbesserung der Leistung.

Fall 1: Mit einer Kaskade löschen

 DELETE FROM table WHERE SomeDate < 7 years ago;

Fall 2: Ohne Kaskade löschen

 FOR EACH R IN (SELECT FROM table WHERE SomeDate < 7 years ago) LOOP
   DELETE FROM ChildTable WHERE tableId = R.tableId;
   DELETE FROM table WHERE tableId = R.tableid;
   /* More child tables here */
 NEXT

Zweitens funktioniert der Code in Fall 1 weiter, wenn Sie eine zusätzliche untergeordnete Tabelle mit einer Kaskadenlöschung hinzufügen.

Ich würde nur eine Kaskade einsetzen, in der die Semantik der Beziehung "Teil" ist. Andernfalls löscht ein Idiot die Hälfte Ihrer Datenbank, wenn Sie Folgendes tun:

DELETE FROM CURRENCY WHERE CurrencyCode = 'USD'
WW.
quelle
5
Da Sie nicht wissen, welche Datenbank Sie verwenden, würde ich vorschlagen, dass Ihr manuelles Löschen schlechter abschneidet als das kaskadierende Löschen, da es nicht auf Sätzen basiert. In den meisten Datenbanken können Sie basierend auf einem Join zu einer anderen Tabelle löschen und haben so einen satzbasierten, viel schnelleren Löschvorgang als das Durchlaufen von Datensätzen.
HLGEM
2

Ich versuche, Löschungen oder Aktualisierungen zu vermeiden, die ich in SQL Server nicht explizit angefordert habe.

Entweder durch Kaskadierung oder durch die Verwendung von Triggern. Sie neigen dazu, Sie irgendwann in den Arsch zu beißen, entweder wenn Sie versuchen, einen Fehler aufzuspüren, oder wenn Sie Leistungsprobleme diagnostizieren.

Wo ich sie verwenden würde, ist die Gewährleistung der Konsistenz für nicht sehr viel Aufwand. Um den gleichen Effekt zu erzielen, müssten Sie gespeicherte Prozeduren verwenden.

pauliephonic
quelle
2

Ich finde, wie alle anderen hier, dass Kaskadenlöschungen wirklich nur am Rande hilfreich sind (es ist wirklich nicht so viel Arbeit, referenzierte Daten in anderen Tabellen zu löschen - wenn es viele Tabellen gibt, automatisieren Sie dies einfach mit einem Skript), aber wirklich ärgerlich Wenn jemand versehentlich eine Kaskade löscht, werden einige wichtige Daten gelöscht, die schwer wiederherzustellen sind.

Der einzige Fall, den ich verwenden würde, ist, wenn die Daten in der Tabellentabelle stark kontrolliert werden (z. B. eingeschränkte Berechtigungen) und nur durch einen kontrollierten Prozess (wie ein Software-Update) aktualisiert oder gelöscht werden, der überprüft wurde.

Jen A.
quelle
1

Ein Löschen oder Aktualisieren von S, bei dem ein in einigen Tupeln von R gefundener Fremdschlüsselwert entfernt wird, kann auf drei Arten behandelt werden:

  1. Ablehnung
  2. Vermehrung
  3. Aufhebung.

Die Ausbreitung wird als Kaskadierung bezeichnet.

Es gibt zwei Fälle:

‣ Wenn ein Tupel in S gelöscht wurde, löschen Sie die darauf bezogenen R-Tupel.

‣ Wenn ein Tupel in S aktualisiert wurde, aktualisieren Sie den Wert in den R-Tupeln, die darauf verweisen.

Mayank Chopra
quelle
0

Wenn Sie an einem System mit vielen verschiedenen Modulen in verschiedenen Versionen arbeiten, kann es sehr hilfreich sein, wenn die kaskadengelöschten Elemente Teil des PK-Inhabers sind / diesem gehören. Andernfalls würden alle Module sofortige Patches benötigen, um ihre abhängigen Elemente zu bereinigen, bevor der PK-Besitzer gelöscht wird, oder die Fremdschlüsselbeziehung würde vollständig weggelassen, wodurch möglicherweise Tonnen von Müll im System verbleiben, wenn die Bereinigung nicht korrekt durchgeführt wird.

Ich habe gerade das Kaskadenlöschen für eine neue Schnittpunkttabelle zwischen zwei bereits vorhandenen Tabellen eingeführt (die Schnittmenge, die nur gelöscht werden soll), nachdem das Löschen von Kaskaden für einige Zeit nicht mehr empfohlen wurde. Es ist auch nicht schlecht, wenn Daten verloren gehen.

Bei enumartigen Listentabellen ist dies jedoch eine schlechte Sache: Jemand löscht Eintrag 13 - gelb aus der Tabelle "Farben", und alle gelben Elemente in der Datenbank werden gelöscht. Außerdem werden diese manchmal auf eine Weise aktualisiert, bei der alle gelöscht werden, was dazu führt, dass die referenzielle Integrität vollständig weggelassen wird. Natürlich ist es falsch, aber wie werden Sie eine komplexe Software ändern, die seit vielen Jahren ausgeführt wird, wobei die Einführung einer echten referenziellen Integrität das Risiko unerwarteter Nebenwirkungen birgt?

Ein weiteres Problem besteht darin, dass die ursprünglichen Fremdschlüsselwerte auch nach dem Löschen des Primärschlüssels beibehalten werden sollen. Man kann eine Tombstone-Spalte und eine ON DELETE SET NULL-Option für den ursprünglichen FK erstellen, dies erfordert jedoch wiederum Trigger oder spezifischen Code, um den redundanten Schlüsselwert (außer nach dem Löschen der PK) beizubehalten.

Erik Hart
quelle
0

Kaskadenlöschungen sind äußerst nützlich, wenn logische Entitäten vom Typ Super und Subtyp in einer physischen Datenbank implementiert werden.

Wenn getrennte Supertyp- und Untertyp-Tabellen verwendet werden, um Supertypen / Untertypen physisch zu implementieren (im Gegensatz zum Aufrollen aller Untertypattribute in eine einzige physische Supertyp-Tabelle), gibt es eine Eins-zu-Tabelle -eine Beziehung zwischen diesen Tabellen und dem Problem wird dann, wie die Primärschlüssel zu 100% zwischen diesen Tabellen synchron gehalten werden.

Kaskadenlöschungen können ein sehr nützliches Werkzeug sein, um:

1) Stellen Sie sicher, dass durch das Löschen eines Super-Typ-Datensatzes auch der entsprechende einzelne Sub-Typ-Datensatz gelöscht wird.

2) Stellen Sie sicher, dass beim Löschen eines Untertypdatensatzes auch der Supertypdatensatz gelöscht wird. Dies wird erreicht, indem ein "statt" -Löschauslöser in der Untertypentabelle implementiert wird, der den entsprechenden Supertypdatensatz löscht, der wiederum den Untertypdatensatz durch Kaskade löscht.

Durch die Verwendung von Kaskadenlöschvorgängen auf diese Weise wird sichergestellt, dass niemals verwaiste Supertyp- oder Untertypdatensätze vorhanden sind, unabhängig davon, ob Sie zuerst den Supertypdatensatz oder den Untertypdatensatz zuerst löschen.

Mark Allen
quelle
Gutes Beispiel. In JPA ist es InheritanceStrategy Joined Table. Für 1): Normalerweise verwenden Sie ein Persistenzschicht-Framework (EclipseLink, Hibernate, ...), das die gelöschte Sequenz für eine verknüpfte Entität implementiert, um zuerst das verknüpfte Teil und dann das Superteil zu löschen. Wenn Sie jedoch über eine grundlegendere Software verfügen, z. B. einen Import- oder Archivierungsjob, ist es praktisch, die Entität einfach durch Ausgeben eines Löschvorgangs für den Superteil löschen zu können. Zu 2): stimme zu, aber in diesem Fall sollte der Kunde bereits wissen, dass er an einem verbundenen / untergeordneten Teil des Unternehmens arbeitet.
Leo