Datenmodell die x-te

[Benrath]

Vielleicht sind um Weihnachten einige wieder generös und oder haben Langeweile.
Ich schlage mich immer noch mit dem Datenmodell unserer Umfrage rum.
An sich läuft das tip top und auch möglich Auswertungen mit Power BI laufen gut.

Jetzt ist mir nur aufgefallen, dass ich häufig End- oder Parenttabellen habe in denen ein paar Fragen gruppiert wurden, die man sonst nicht besser zusammenfassen konnte. Teilweise auch weil, die recht random unterstrukturiert werden.

Das macht mir in Power BI etwas Sorgen, weil ich dann Auswertungen pro Jahr nicht einfach zusammenklicken kann, sondern erst noch neue Spalten erstellen muss, damit richtig aggregiert wird, siehe die Frage hier.

https://stackoverflow.com/questions...395503?noredirect=1#comment115617475_65395503

Jetzt ist nur die Frage, ob ich das teilweise noch im Modell anpasse, wenn die Endtabelle eher selten wiederholte Einträge hat. Ich hab hier z.B. 7 Tabelle, wo die Fragen eigentlich teilweise strukturierbar wären, weil jedes mal nach der Anzahl eines Typs gefragt wird, dann aber in jeder Tabelle irgendwie anders unterstrukturiert wird.



Da ist immer ne Frage nach Anzahl der Häfen, Abstellgleise, Bahnhöfe etc. aber dann z.B. Bahnhöfe größer 1000, die bei den anderen Blöcken nicht vorkommt.

Ich könnte jetzt einfach die Beziehung umdrehen und eine id "unternehmensart_id" einfügen, die auf die id in unternehmensarten verweist. Schöner wäre es wohl, wenn ich die Tabellen doch noch in eine Tabelle zusammenfasse und in Haupt und Unterkategorien aufteile..

Dann klappt alles mit zusammenklicken in Power BI.

 

[parats']

Du hast die ideale Lösung ja schon selbst geschrieben.
Allerdings müsstest Du dir was überlegen für alle Informationen die über die Anzahl hinausgehen.
Für einen ersten Versuch reicht wahrscheinlich eine Umwandlung der Tabelle in einen Integer als Gruppe plus eine Zerteilung der Tabelle wobei jede Spalte als Typ mit der Unternehmensart und Gruppe einen Schlüssel auf der Zeile bildet. Im Prinzip nichts anderes als transponieren in Excel und der Wert bildet wie gewohnt das measure.

 

[Benrath]

Gibt es denn keine Argumente für die aktuelle Variante? Meinetwegen speichertechnisch, für die Datenintegrität, etc.? Die Designentscheidung hatte damals der Berater getroffen und ich war noch nicht so weit die Auswirkungen zu verstehen.

Ich müsste mir jetzt viel Mühe geben das alles umzumodeln, nur damit nachher jeder Depp in Power BI was zusammenklicken kann.
Dabei könnte ich auch einfach ne View erstellen, wo ich das alles auf unternehmensarten left_joine.

Wenn ich das richtig verstehe haben meine End-Tabellen jetzt recht wenig Zeilen, weil sie 1 zu N auf die unternehmensarten verweisen.
Wenn ich das drehe und eine N zu 1 Verbindung draus mache werden die Tabellen länger und die FK Id geht in die "kleinen" Tabellen.
Dafür gewinn ich den Komfort in Power BI, dass ich direkt auswerten kann.

Ist es für die Datenintegrität besser, wenn ich den Eintrag in unternehmensarten erst erstellen kann, wenn die Einträge in den End-Tabellen stehen oder eher egal?

Die Ideale Lösung wäre dann sowas? Dadurch würde ich aber verschiedene Datentypen in eine Spalte vermischen oder die eine Text Spalte woanders hinverschieben.

id	unternehmen_id	Serviceeinrichtung	Attribut	Wert
1	1	Hafen	Anzahl	10
1	2	Hafen	unternehmen	TEXT asdf
1	3	Personenbahnhof	Anzahl	10
1	4	Personenbahnhof	Größer 1000	5
1	5	Abstellgleise	Anzahl	8

 

[Benrath]

Ich hab z.B. auch solche Beziehungen, bei denen in den Endtabellen nur True/False zu gewissen Eigenschaften stehen. Da find ich das so in den Reihen für Selektionen, ob z.B. jemand ein Typ ist und den nicht genutzt hat für jedermann verständlicher.

Außerdem seh ich schneller welche Permutation wie häufig vorkommen.

 

[parats']

Du kannst das Modell schon so behalten, aber du bist halt relativ gefangen in der Struktur, wenn man erweitern muss.
Das würde jedes mal eine neue Entität bedeuten und eine Anpassung der Unternehmensart Tabelle für die PK/FK Relation.
Ein drehen der Relation kann schon ausreichen - also deine Idee die Unternehmensart in die Einzelnen Tabellen zu legen.
Dein Beispiel geht schon in die Richtung, du willst am Ende eine Zeile haben, die vorher eine Spalte. Du transponierst also vom Spaltennamen in eine Zelle.

Von:
Bahnhöfe >1000 (Spaltenname)
400 (Anzahl)

Nach:
Typ | Anzahl
Bahnhöfe >1000 | 400

Und dazu eben die Schlüssel für die Aggregation.

Das du da generell wenig Lust drauf hast glaube ich gerne. Es ist vor allem ein experimentieren, wenn man noch nicht 100% wo es mal hin gehen soll/kann.
Wenn du abschätzen kannst, dass die Nutzung des Modells sich nicht groß verändert, dann wird eine Umstellung per View bzw. Kleine Anpassung an der Relation wohl deutlich schneller gehen, als nochmal alles neu zu machen.
Performance wäre dann mal nachgelagert, je nach Größe der Tabellen sind Left joins halt arg langsam.

P.s.
Früher hat man sich eher für breite Tabellen entschieden, dass hat sich aber seit vielen Jahren hin zu langen Tabellen geändert, vor allem weil das laden der Inhalte in den Arbeitsspeicher deutlich effizienter geworden ist.

 

[Benrath]

Ich versuch hier alle von long zu überzeugen aber wide ist leider das was man kennt etc. Hab das in anderen Bereichen des Datenmodells, wo es gleich klarer war auch stärker umgesetzt


free site to upload pictures

Mich ärgert es jetzt nur etwas, dass dann bei so simplen Endtabellen eher zum Krampf wird.

Du kannst das Modell schon so behalten, aber du bist halt relativ gefangen in der Struktur, wenn man erweitern muss.
Das würde jedes mal eine neue Entität bedeuten und eine Anpassung der Unternehmensart Tabelle für die PK/FK Relation.
Ein drehen der Relation kann schon ausreichen - also deine Idee die Unternehmensart in die Einzelnen Tabellen zu legen.
Dein Beispiel geht schon in die Richtung, du willst am Ende eine Zeile haben, die vorher eine Spalte. Du transponierst also vom Spaltennamen in eine Zelle.

Das versteh ich nicht ganz. Was meinst du mit Entität? Eine Tabelle oder Spalte?
Eine neue Tabelle kann ich doch auch in der Struktur recht einfach einfügen und den FK_ID in die unternehmensarten nachträglich einfügen. Spalten bei den bereits existierenden Tabellen auch.

Ich glaub ich mach es jetzt bei dem ersten Beispiel noch, weil es tatsächlich 7 Tabellen in eine zusammenlegt und weil man gerade diese Werte auch eher mal zusammen auswerten würde. Das erste Attribut gibt es schon als Metatabelle, die zweiten sind halt etwas random, aber könne ich auch noch eine Untertabelle erstellen.

Auf der anderen Seite ist es ärgerlicher, dass ich das nicht schon früher so gemacht habe, weil die Migration der Altdaten ist so zumindest für mich einfacher. Beim zweiten Beispiel lasse ich es jetzt so, weil mich sonst auch mein Dienstleister killt, weil sie das schon umsetzen.

So sähe es dann aus.

 

[parats']

Entität in diesem Fall Tabelle.
Du musst im Modell oben eine neue Tabelle anlegen und bei der bestehenden eine Spalte für den FK anlegen. Dazu muss entschieden werden, was bei den existierenden Einträgen als FK vergeben wird.
Du musst halt u.U. nach x Jahren entscheiden wie du mit alten Datensätzen dann umgehen willst, damit diese in der Auswertung eine Berücksichtigung finden. Hier einen Konsens zu finden kann aufwendig sein, vor allem wenn viele Leute damit arbeiten. In jedem fall wird man einen Default brauchen um kein NULL in der Referenz zu haben.

Wenn du verschiedene Attribute (im Sinne von Ja/Nein) darstellen musst, die nicht unbedingt deckungsgleich sind, dann kann man es entweder als Junk Dimension versuchen, das ist dann zwar nicht so schön lesbar dafür aber ziemlich performant. Alternativ gibt es Konstrukte, die an das Rechtesystem von Linux angelehnt sind und halt auf zweier Potenzen und den Kreuzprodukten basieren.
Das ist bis zum Smallint noch umsetzbar, danach sprengt die Menge an Kombinationen aber den Nutzen zu Lasten der Performance.

 

[Benrath]

Entität in diesem Fall Tabelle.
Du musst im Modell oben eine neue Tabelle anlegen und bei der bestehenden eine Spalte für den FK anlegen. Dazu muss entschieden werden, was bei den existierenden Einträgen als FK vergeben wird.
Du musst halt u.U. nach x Jahren entscheiden wie du mit alten Datensätzen dann umgehen willst, damit diese in der Auswertung eine Berücksichtigung finden. Hier einen Konsens zu finden kann aufwendig sein, vor allem wenn viele Leute damit arbeiten. In jedem fall wird man einen Default brauchen um kein NULL in der Referenz zu haben.

Axo, ja stimmt, wobei ich Rückwirkend halt einfach NULL setzen würde, weil die Tabelle einfach vorher nicht existiert hatte. Es gibt in einer Übertabelle noch eine Zeitdimension. Das wäre natürlich der Vorteil deiner Variante ist, weil ich dann flexibler bin

Vor und Nachteil ist teilweise noch Löschen. Jetzt kann ich die Einträge der Endtabelle wegen der FK Beziehung zu unternehmensarten nicht löschen.
In der anderen Variante könnte ich die Einträge löschen, aber nichts mehr in unternehmensarten löschen, wenn ein Einträge aus der Tabelle auf einen Eintrag dort verweist.

 

[parats']

NULL wäre blöd, weil Du dann immer mit einem left join arbeiten müsstest, sofern der FK in deiner Unternehmensartentabelle NULL ist. Daher nimmt man dafür einen default Wert. Beispielsweise -1 als ID für unbekannt, sofern die Daten es hergeben und es keine Nutzdaten auf dem Eintrag gibt.

Fürs löschen kann man mit cascading delete viel raus holen, dann bleiben die Daten auch sauber.

Am Ende des Tages muss man sich nichts vor machen. Viele Datenmodelle sind solange "gut" bis sich die Anforderung ändert bzw. eine neue dazu kommt.
Wenn abzusehen ist, dass das hier ein Stand X eingefroren wird und dann war es das, dann lohnt sich der Aufwand wohl nicht.
Vor allem wenn Berater schon vorab tätig waren und dort Abhängigkeiten bestehen.

 

[Benrath]

NULL wäre blöd, weil Du dann immer mit einem left join arbeiten müsstest, sofern der FK in deiner Unternehmensartentabelle NULL ist. Daher nimmt man dafür einen default Wert. Beispielsweise -1 als ID für unbekannt, sofern die Daten es hergeben und es keine Nutzdaten auf dem Eintrag gibt.

Ah gut zu hören. Ich hatte teilweise einfach ne komplette NULL / NA Zeile mitgeführt, so das meine ID = 1, die leeren Zeilen darstellt.
Auf der anderen Seite ist das doch auch das Problem, wenn ich die Beziehung umdrehe? Irgendwann brauch ich dann doch was anderes als einen Inner Join, wenn ich Angst hab Reihen zu verlieren.

Fürs löschen kann man mit cascading delete viel raus holen, dann bleiben die Daten auch sauber.

Hatten wir zur Sicherheit erstmal alles auf aus gestellt. Hab noch nicht so ganz verstanden, wie ich das zwischenzeitlich aktivieren kann
Musste fürs ein subset erst kompliziert alle anderen Daten löschen 8(

Am Ende des Tages muss man sich nichts vor machen. Viele Datenmodelle sind solange "gut" bis sich die Anforderung ändert bzw. eine neue dazu kommt.
Wenn abzusehen ist, dass das hier ein Stand X eingefroren wird und dann war es das, dann lohnt sich der Aufwand wohl nicht.
Vor allem wenn Berater schon vorab tätig waren und dort Abhängigkeiten bestehen.

Also der Berater hat insgesamt 35 PT mit uns verbracht und davon erst mal 10-15 gebraucht alles zu sichten. Die meisten "Verbesserungen" mit Blick auf Usability kommen jetzt von mir. Hoffentlich sind es Verbesserungen

Wir haben die Fragebögen seit 2006 aber hab gerade auch nicht den Überblick wieviel wirklich über alle Jahre konstant abgefragt wurde.
An der generell Struktur sollte sich aber nicht viel ändern. Neue Fragen oder Blöcke von Fragen müssen schon in die generelle Struktur passen, die sich ziemlich sicher sobald nicht ändert.

 

[parats']

Ja, das hast Du leider in beiden Modellen.
Ich bin grundsätzlich kein Freund von outer joins (left, right, full), da gerade bei vermeintlichen cascading joins von Tabelle A über Tabelle B auf Tabelle C der erste Left Join auf Tabelle B implizit ein Inner Join wird, wenn dieser von B auf C geht. Das ist trügerisch, weil viele immer davon ausgehen, dass man in seinen Fakten ja nichts verlieren kann, wenn nur fleißig mit outer joins gearbeitet wird.
Ausnahmen gibt es genügend, aber einfache selects sollten nach Möglichkeit ohne auskommen.

Ein Standardwert für unbekannt schadet jedenfalls nicht und du verlierst auch nichts an Zeilen.

Cascading on Delete ist eine Eigenschaft des Constraints auf Tabellenebene.

 

[Benrath]

Cascading on Delete habe ich für alle Tabellen deaktiviert. Hatte gehofft, das es eine Variante gibt, wie man einmalig für einen Request die Option überschreiben kann und doch mit Cascade löschen kann.

Ich hab mir noch paar Gedanken gemacht und bin jetzt auch noch mehr überzeugt, dass es Sinn macht die FK in die aktuellen Endtabellen zu schieben.
Anders gesprochen sind meine Endtabellen ja eigentlich Facttables die Werte zu gewissen Fragen speichern. Die Dimension tables sind unternehmen und unternehmensarten, die die Information zur ID des Unternehmens, des Jahres, und des Fragebogentyps enthalten. Dann macht es mehr Sinn, wenn die Factables die Childs zu den Dimensiontables sind.

Im Regelfall ist der Unterschied in den Anzahl der Reihen der Endtabellen auch gering. OB die Endtabelle jetzt 1000 Einträge oder 2000 hat ist wohl egal.
Komfort der Direktnutzung in Power Bi ist wichtiger.

Sonst gehen halt noch Bridge Tables, wenn es sich lohnt und ich die einzelnen Spalten meiner Endtabellen sinnvoll Gruppieren kann. Für jede Tabelle mach ich das jetzt aber nicht. Wenn was neues dazukommt ist die Spalte halt NULL in die Vergangenheit. So hab ich auch nicht ständig FKs mit NULL wie aktuell.

Frage mich einfach nur was sich der Berater dabei gedacht hatte ....

 

[parats']

Wozu eine bridge table?
Damit löst du eigentlich nur n:m Relationen auf.
Ich weiß ja nicht mit wem ihr arbeitet, aber eine der großen Business Intelligence Agenturen wird es hoffentlich nicht sein.

 

[Benrath]

Ja die Bridge Table stellt die m:n Verbindung zu den Fragen / Kategorien her, so wie oben besprochen.
Ich mache mir aber nicht die Mühe, das für jede Tabelle zu machen, wenn es keine wirkliche übergreifende Struktur gibt.



Bei der einen Tabelle bvse_infrastrukturen macht es Sinn, weil ich das für X Typen von Serviceinrichtungsarten abfrage und gewisse Unterkategorien ("Anzahl", "Anzahl gemietet") übergreifend gefragt werden.

In der Tabelle bvse_sonstiges sind es wirklich nur die 8 Fragen. Und da hab ich jetzt keinen Nerv das ist ne extra Metatabelle mit X Einträgen zu schieben.
Der Vorteil wäre, wenn ich es richtig verstanden habe. Das ich eine 9. Frage in die Metatabelle setzten könnte und ich rückwirkend nicht irgendetwas auf Null setzen muss. Sonst adde ich einfach eine 9. Spalte zu bvse "sonstiges" und die ist immer Null für die bereits existierenden Einträge der Vergangenheit.

Man sieht jetzt das in Unternehmensarten nur noch eine FK Beziehung zu einer Tabelle "unternehmen" besteht in der die Zeitinformation zum Jahr der Abfrage enthalten ist. Die Tabellen aus Post #4 lasse ich jetzt so. Das Beispiel aus Post #1 und ähnliche Tabellen wie bvse_sonstige habe ich jetzt alle angepasst. Meistens hat sich die Zahl der Einträge pro Tabelle nur leicht erhöht. Je mehr Spalten desto geringer der UNterschied, weil weniger Duplikate. Vielleicht ärger ich mich mal in drölf Jahren, aber ich glaub da kommt nix über 10.000 Zeilen.


Unser Rahmenvertragsanbieter war Bearing Point der uns dann an eine andere Firm connet-edv weitervermittelt hatte. Habe da dank oder wegen des Rahmenvertrags keine Wahl. Dafür muss ich auch nicht erst 3 Monate ausschreiben etc.
Ich hab dem Berater mal ne Email geschickt, ob er das noch nachträglich begründen kann.

 

[Benrath]

Nochmal ne wahrscheinlich blöde Frage.

Die PK meiner Tabellen haben bei AutoNum alle TRUE stehen. Daher schiebe ich die Daten ohne die PK-id Spalte auf die Datenbank.

Kann ich das ex-post ändern ohne Daten zu verlieren? bzw. ohne die ID spalte zu löschen und neu zu erstellen, was wegen anderer Constraints nicht geht.?

 

[parats']

Du willst im Prinzip das AutoIncrement entfernen?
Prinzipiell sollte es gehen, zumindest in MS SQL sehe ich da kein Problem auf Seiten des DBMS.
Falls es nicht geht, weil <insert random reason> dies verhindert kannst Du es nur über verschiedene Umwege versuchen die im Prinzip aber ein löschen/erstellen sind..

Spontan fällt mir folgendes ein:
- Neue Spalte zum temporären halten der alten Werte, alte Spalte entfernen und neue umbenennen
- CREATE TABLE AS Statement (sofern es das gibt)

Mach vorher ein Backup und versuch dich einfach mal.

 

[Benrath]

Du willst im Prinzip das AutoIncrement entfernen?

100 Punkte :P

Naja und ich frage mich noch, ob ich das machen muss oder ich, wenn mir später daten aus der Webschnittstelle rüber geschubst werden sollen.
Daher denke ich, dass ich das wohl wollen muss.

Die Anpassung über den EA ging leider nicht, weil er genau, dass machen will was du sagst, ohne das mit der temporären Spalte.
Blöd ist dass das die IDs zwischenzeitlich für andere FK Constraints wichtig sind daher müsste ich die auch immer anpassen und kurzfristige auf die Tempspalte legen.

An sich könnte ich es eher so machen
1. Spalte kopieren mit Temp namen
2. Constraint anpassen auf die Temp Spalte legen (hier ist blöd dass der constraint ja in ner anderen Tabelle liegt...)
3. Alte Spalte löschen
4. neue Spalte zum PK machen.
5. Umbennen (je nachdem im Constraint noch Namen anpassen...)


Das jetzt für alle Tabellen manuell wäre blöd... mal gucken, obs mit nem Loop geht....


Ärglicher ist, dass ich da vor Monaten drüber nach gedacht aber nicht wusste ob AutoIncrement TRUE oder FALSE besser ist, der Berater aber immer TRUE genommen hatte....

 

[parats']

Stört dich das Auto Increment denn so?

 

[Benrath]

Das weiß ich noch nicht aber ich wollte nur gerüstet sein falls es das tut.

Perspektivisch hab ich neue Daten des selben Models einmal auf einer Oracle DB woanders liegen und will mir dann z.B. täglich ein Update ziehen und in meine MS SQL DB ziehen. Noch weiß ich nicht, ob mich das Auto Increment stören wird.

 

[parats']

Also in der Theorie sollte es nicht stören. Es gibt immer Konstrukte wie z.B. separate Schlüsseltabellen um mehrere Quellen für identische Dimensionen auf einen Nenner zu bringen, wo ein Auto Increment stört. Aber das findet sich im Datawarehouse Bereich wieder und betrifft dich sicherlich nicht.
Was Du ansonsten machen kannst, schreib dir ein Skript was über die Metatabellen alle Informationen ausliest und daraus SQL Statement generiert. Darüber kann man dann auch das löschen/anlegen von etwaigen constraints "steuern".

 

[Benrath]

Aber das findet sich im Datawarehouse Bereich wieder und betrifft dich sicherlich nicht.

You or I wish

Sowas haben wir nicht, hätte ich ja gerne. Ich arbeite dran 8(

 

[parats']

Okay, hörte sich bisher nur nicht so an, als wird das mal ein richtiges Datawarehouse. Dinge entwickeln sich aber natürlich gerne mal in Richtungen die man so nicht gesehen hat.

 

[Benrath]

Bis dahin ist noch ein weiter Weg. ÖD for the win

 

[parats']

Ich würde bei dem Tempo wahrscheinlich depressiv werden. Hut ab wie man sowas aushält.

 

[Bootdiskette]

Ich fühle übrigens Deinen Schmerz Benrath. Bin grad dabei zu versuchen eine große Migration der zentralsten Datenbank unseres Ladens zu beeinflussen … dummerweise hab ich ständig das Gefühl, dass ich der einzige bin der irgendwie ein Interesse an einem verbesserten Datenmodell hat während alle Kernentwickler schon seit Ewigkeiten an dem alten Ding rumgeschraubt haben und eigentlich nur wollen, dass sich nichts ändert.
Ich krieg immer die Krise wenn ich die zig Tabellen sehe bei denen niemand im Unternehmen mehr weiß wozu sie gut sind, ob man sie noch braucht, oder ob man sie theoretisch gefahrlos löschen könnte. Brrr.

 

[Benrath]

Willkommen

Ich hab gerade eher noch den Schmerz die Altdaten aus der MS SQL DB in eine Oracle DB zu migrieren.
Ich muss jetzt erst alle Tabellen meiner MS SQL DB als CSV files exportieren und die durch ein Skript (Talent) jagen, dass dann für jede Zeile ein Insert Into schreibt. Daraus ergibt sich dann ein 80 MB Skript. Und jetzt find der Spaß an Sonderzeichen usw. auszumerzen...

 

[parats']

MSSQL hat da für den Export in CSV ne Art Umweg und einen Wizzard. Musst mal auf der DB im Kontextmenü suchen, da gibt es irgendwo einen Punkt "script as" und dann viele Unterpunkte. Vielleicht hilft dir das zumindest im ersten Schritt.

Eine alternative wäre SSIS und dann einfach von MSSQL ziehen und in Oracle schreiben.

€: Eben nochmal geschaut: Tasks -> Generate Scripts

 

[Benrath]

Ja SSIS wurde mir auch genannt und geht aber aus drölf anderen Gründen nicht.

Skripte erstellen exportiert glaub ich nur das Datenbankmodell. Damit hab ich kein Problem aktuell, weil mein Datenbankerstellungsskript aus EA kommt.

Auf der anderen Seite funktinoiert es jetzt auch nachdem ich alles angepasst habe

 

[parats']

SSIS ist vor allem relativ aufwendig, wenn es ad hoc sein soll.
Je nach Installation deines Microsoft BI Stacks braucht man ggf. nochmal einen extra Treiber, wenn der default ODBC nicht will.
Zumindest bei SAP HANA oder IBM AS400 ist das zum Teil ein richtiger Krampf und limitiert da bei größeren Datenmengen auch gerne.

Wenn du jetzt aber ohnehin klar kommst, dann passt es ja. gl hf.

 

[Benrath]

Vielleicht könnt ihr mir noch mal generell mit SQL bzw. doch dem Design helfen.

Ich hab bei allen FK Constraints die On Delete Option auf "No Action" gesetzt, weil ich nicht wollte, dass man Einträge mit FK Beziehungen einfach löschen kann. Ich möchte schon gerne Einträge z.B. in einer Tabelle "Personen" löschen, aber dann explizit einen andere id als replacement angeben. (bzw. muss ich dank DSGVO personen die seit X Jahren nicht mehr genutzt sind) eigentlich löschen.

Naiv wie ich bin hätte ich mir sowas vorgestellt.

Delete
Delete from personen where id= 1
update FK_id=2

so dass überall die FK_ids = 1 (es können leider mehrere sein) mit einer 2 ersetzt werden.

Wenn ich es mir einfach machen will, muss ich Tabelle einfach auf "set Null" setzen. Kann ich das temporär machen?

Was mache ich denn wenn ich generell Personen Umcodieren möchte, weil ich merke das z.B. Id 1 und 2 dieselbe Person nur mit unterschiedlicher Schreibweise ist?

 

[parats']

Auf die schnelle könnte man es mit einem Trigger versuchen. Für "For Delete" müsste man den PK des zu löschenden Datensatzes in der FK Tabelle einfiltern und ein Update absetzen. Allerdings ist das natürlich relativ statisch, daher müsste man wohl einen N/A Wert verwenden um kenntlich zu machen, dass es diese Person nicht mehr gibt und man daher ein default verwendet.

Für das generelle umschreiben des FKs, also beim zusammenlegen, brauchst Du ohnehin eine Routine, die solch eine Erkennung vornimmt.
Gerade bei phonetischen Abgleichen wäre ich aber vorsichtig. Dir geht es sicherlich um sowas wie Müller und Mueller, oder?
Wenn ja, müsste man vorab einen Standard definieren um gewisse Sachen abzufangen, dass ist aber auch mehr oder minder "statisch", da man immer nacharbeiten muss.
In der Logistik nutzen wir was selbst entwickeltes mit dem wesentlichen Kern ElasticSearch + viel drumherum, da geht es aber viel mehr darum _den_ gültigen Adressdatensatz herauszufinden um die Datenqualität zu verbessern, was das ansteuern von Adressen innerhalb von Postleitzahlen ermöglicht. Wahrscheinlich eine zu große Kanone für einen zu kleinen Spatz in deinem Fall.

Wir haben damals auch viel mit Fuzzy herumgespielt, aber das ist einfach sau träge gewesen und relativ fehleranfällig, wenn dort mit niedrigen Genauigkeiten arbeitet.

 

[Benrath]

Hmm puh kompliziert

ich glaub ich mache jetzt tatsächlich so, dass ich z.B. für die FK auf Personen die On Delete auf Null setze und ich mir auch noch mal die Bedingungen der FK ids in den anderen Tabellen anschauen muss, dass die NULL zulassen.

Ach die Konsolidierung doppelter bzw. änlicher Einträge vererbe ich an wen anders. Bei den Personen ist es tatsächlich irgendwie egal.
Gäbe eher so Handelsregistereinträge, die in der Vergangenheit scheisse aussehen, aber die Mühe ...

 

[Benrath]

Ja, das hast Du leider in beiden Modellen.
Ich bin grundsätzlich kein Freund von outer joins (left, right, full), da gerade bei vermeintlichen cascading joins von Tabelle A über Tabelle B auf Tabelle C der erste Left Join auf Tabelle B implizit ein Inner Join wird, wenn dieser von B auf C geht. Das ist trügerisch, weil viele immer davon ausgehen, dass man in seinen Fakten ja nichts verlieren kann, wenn nur fleißig mit outer joins gearbeitet wird.
Ausnahmen gibt es genügend, aber einfache selects sollten nach Möglichkeit ohne auskommen.

Ein Standardwert für unbekannt schadet jedenfalls nicht und du verlierst auch nichts an Zeilen.

Cascading on Delete ist eine Eigenschaft des Constraints auf Tabellenebene.

Hab heute gemerkt was du meinst. Von Tabelle A über B zu C die Left joins und mich gewundert, dass ich weniger hatte als ich dachte. Weils ne 1:M Beziehung, gehen mir die Einträge aus A nicht verloren, wenn über B zu C nichts existiert. Das ist ja ok. Doof ist nur wenn ich gerne nur ein m aus M haben möchte und dann der Eintrag doch ganz flöten geht, weil ein anderes m aus M ja getroffen wurde.

Noch viel ich lernen muss, bzw. hoffentlich andere sich damit rumschlagen müssen.

 

[parats']

Je nach Situation kann man ja mit nested joins arbeiten. Grundlegend müsste man halt abschätzen, ob das Modell so verzweigt ist, dass sich ein Mehraufwand für bspw. Inferred Member lohnt. Je mehr das Modell Richtung Star schema geht, desto so unwahrscheinlicher lohnt sich der Mehraufwand. Im Gegenzug kann bei starken Snowflake schema Ansätzen der Aufwand den Nutzen rechtfertigen. Outer Joins sind bei großen Teilmengen einfach langsam, von daher muss man sowas immer abwägen.