akretschmer
Datenbank-Guru
- Beiträge
- 10.328
nicht ganz ...
möglicherweise ist das nur eine abstrakte Beschreibung für etwas anderes.
Automatisches Erzeugen eines PK bei Insert eines FK
- Ersteller Tom.S
- Erstellt am
möglicherweise ist das nur eine abstrakte Beschreibung für etwas anderes.
Werbung:
Kann sein das Postgre damit seine Probleme hat... Aber zumindest Oracle ist es schlichtweg egal
Es hat in keiner Art und Weise Auswirkungen auf das Verhalten...
Wenn es sich wirklich um so viele abstrakte Datenformen handelt sollte man dann nicht spätestens hier auf objektorientierte Datenbanken verweisen? Weil es sich dann um etwas handelt, was eine "einfache" Relation nicht darstellen kann... Wobei ich derzeit der festen Überzeugung bin sein Modell lässt sich reduzieren... Es hört sich zumindest so an
akretschmer
Datenbank-Guru
- Beiträge
- 10.328
PG hat ein Limit von max. so 1600 IIRC, laut Google Oracle entweder von 1000 oder 32.000, ich fand unterschiedliche Angaben. Davon abgesehen denke ich, alles was 3-stellig ist dokumentiert ein schlechtes Design.
Damit behauptest du sämtliche Data-Warehouse Tools die auf Oracle laufen sind schlecht designed 
Nein, im Gegenteil... Genau dafür ist dieses Maximum gedacht
Die Anzahl Spalten hat sich über die Versionen verteilt immer wieder erhöht... Ab der 12-er Version sind es 32000
Nein, im Gegenteil... Genau dafür ist dieses Maximum gedacht
Die Anzahl Spalten hat sich über die Versionen verteilt immer wieder erhöht... Ab der 12-er Version sind es 32000
Ich sehe, das Beispiel war einfach schlecht gewählt, weil es die Ähnlichkeit der Subtabellen nahelegt.
Weil sich mir dieses Problem dauernd stellt und ich mich wundere, dass es so ungewöhnlich zu sein scheint, gebe ich ein reales Beispiel aus einem meiner Projekte:
Ein Real-World-Szenario soll abgebildet werden: Wir haben Vermieter, Mieter, Arbeitgeber, Firmenanteilseigner und zahlreiche weitere ähnliche Verhältnisse.
Ich habe in meinem Datenschema jetzt Personen und Organisation (worunter auch Behörden oder Unternehmen fallen).
Das Problem ist jetzt, dass die obigen Rollen sowohl von Personen als auch von Organisationen ausgefüllt werden können: Eine Person kann einen Raum mieten oder ein Unternehmen. Eine Person kann jemanden beschäftigen genauso wie ein Unternehmen dies kann.
Wenn ich jetzt zahlreiche Fremdschlüssel in den vermietet_von, beschaeftigt_bei, ... Tabelle habe, die auf die jeweilige Person oder Organisation verweisen sollen, dann brauche ich alle Koppelungstabellen und FK-Spalten in doppelter Ausführung: Einmal für Personen und einmal für Organisationen.
Und jetzt kommt meine Idee ins Spiel, Organisationen und Personen in einer Supertabelle "juristische_person" zusammenzufassen. Diese Tabelle hat im Grunde nur eine pk-Spalte und in der Personen- und Organisationstabelle verweise ich per FK darauf. Das spart mir die Doppelung (in meinem realen Szenario waren das 10% an Tabellen und Spalten).
Damit das richtig funktioniert, müssen die Super- und Subtabellen automatisch ganz eng an einander gekoppelt werden. Nach meiner Überlegung, würde dies am besten mit einem Before-Insert-Trigger funktionieren, der einen Eintrag in der "juristische_person"-Tabelle vornimmt.
Die Auswertung wird dadurch natürlich etwas komplexer, aber auch einfacher, weil ich nicht zwei unterschiedliche Tabellen "beschaeftigt_bei_person" und "beschaeftigt_bei_organisation" auswerten muss.
Habt Ihr nicht auch solche Szenarien und löst Ihr sie ganz anders?
Weil sich mir dieses Problem dauernd stellt und ich mich wundere, dass es so ungewöhnlich zu sein scheint, gebe ich ein reales Beispiel aus einem meiner Projekte:
Ein Real-World-Szenario soll abgebildet werden: Wir haben Vermieter, Mieter, Arbeitgeber, Firmenanteilseigner und zahlreiche weitere ähnliche Verhältnisse.
Ich habe in meinem Datenschema jetzt Personen und Organisation (worunter auch Behörden oder Unternehmen fallen).
Das Problem ist jetzt, dass die obigen Rollen sowohl von Personen als auch von Organisationen ausgefüllt werden können: Eine Person kann einen Raum mieten oder ein Unternehmen. Eine Person kann jemanden beschäftigen genauso wie ein Unternehmen dies kann.
Wenn ich jetzt zahlreiche Fremdschlüssel in den vermietet_von, beschaeftigt_bei, ... Tabelle habe, die auf die jeweilige Person oder Organisation verweisen sollen, dann brauche ich alle Koppelungstabellen und FK-Spalten in doppelter Ausführung: Einmal für Personen und einmal für Organisationen.
Und jetzt kommt meine Idee ins Spiel, Organisationen und Personen in einer Supertabelle "juristische_person" zusammenzufassen. Diese Tabelle hat im Grunde nur eine pk-Spalte und in der Personen- und Organisationstabelle verweise ich per FK darauf. Das spart mir die Doppelung (in meinem realen Szenario waren das 10% an Tabellen und Spalten).
Damit das richtig funktioniert, müssen die Super- und Subtabellen automatisch ganz eng an einander gekoppelt werden. Nach meiner Überlegung, würde dies am besten mit einem Before-Insert-Trigger funktionieren, der einen Eintrag in der "juristische_person"-Tabelle vornimmt.
Die Auswertung wird dadurch natürlich etwas komplexer, aber auch einfacher, weil ich nicht zwei unterschiedliche Tabellen "beschaeftigt_bei_person" und "beschaeftigt_bei_organisation" auswerten muss.
Habt Ihr nicht auch solche Szenarien und löst Ihr sie ganz anders?
akretschmer
Datenbank-Guru
- Beiträge
- 10.328
ich finde die Idee jetzt so schlecht nicht. Vielleicht noch ein Constraint, daß eine juristische Person eine natürlich oder eine Organisation sein muß, aber das ist easy.
Werbung:
Ja, in diesem Fall ist das ja auch richtig... Eine Person ist was anderes als eine Organisation...
Aber in deinem vorherigen Beispiel wolltest du für die gleich Art von Daten (Auto-Hersteller) verschiedene Tabellen anlegen... Das ist so als würdest du in deiner Organisation zwischen GmbHs und AGs unterscheiden... Total unsinnig Natürlich wird es Daten geben die nur für eine der beiden Untergruppen vorhanden sind, das heißt ja aber nicht dass man Sie grundsätzlich trennen muss...
Aber in deinem vorherigen Beispiel wolltest du für die gleich Art von Daten (Auto-Hersteller) verschiedene Tabellen anlegen... Das ist so als würdest du in deiner Organisation zwischen GmbHs und AGs unterscheiden... Total unsinnig
Natürlich wird es Daten geben die nur für eine der beiden Untergruppen vorhanden sind, das heißt ja aber nicht dass man Sie grundsätzlich trennen muss...