Fremdschlüsselproblem

[TheBeast]

Hallo Frank,

hat ein wenig gedauert, aber ich lasse das natürlich nicht auf mir sitzen

ich habe deine Lösung getestet und dazu noch meine aufgebaut.
Es ist bei 147k Datensätzen ein Unterschied von 6/100Sek
festzustellen.
Die Composite-Index-Lösung ist schneller.

Das noch als objectiv schneller zu bezeichnen müsste Dir aber schon auch selbst schwer fallen, oder?

Dein Problem mit dem Gleichartikeit(1) von Objekten ist
Definitionssache
wenn ich definiere, das dass Wohnobjekt in einer Tabelle
gespeichert wird ist das eben so(In einem
Warenwirtschaftssystem würdest du doch auch Häuser und
Kühlschränke im Artikelstamm aufnehmen, wenn diese verkauft
werden, wo ist da die Gleichheit? Oder legst du für jede
Artikelgruppe eine neue Tabelle an?).

Nein, ich lege natürlich nicht für jede Artikelgruppe eine eigene Tabelle an. Dass allerdings Häuser und Viertel das Gleiche sind hast Du definiert, nicht der OP. Ohne also mehr über das eigentliche Datenmodell zu wissen tun wir uns da schwer.

Spätestens wenn die zwei Tabellen so aussehen finde ich Deinen Ansatz wirklich uneingeschränkt falsch:

GEBAEUDE
 id
 adresse1
 adresse2
 viertel\_id
VIERTEL
 id
 bezeichnung
 plz

Das einzige, was in Deiner Mischtabelle dann immer gefüllt wäre ist der Primary Key - ein mehr als deutlicher Hinweis, dass da was schief läuft. Der sähe dann ja so aus:

GEBAEUDE\_VIERTEL
 typ
 id
 adresse1
 adresse2
 viertel\_id
 bezeichnung
 plz

Wie Du da verhinderst, dass jemand ein Viertel löscht an dem noch Gebäude hängen (oder ein Gebäude einfügt, das auf ein nicht existentes Viertel verweist) wäre übrigens auch interessant.

Bleibt nur noch Punkt 3, ich könnte dein System auch nicht
intuitiv bedienen.

Na schön. Uns fehlt noch die Tabelle, die sich auf Gebäude/Viertel bezieht. So sähe die bei mir aus:

PERSON
 id
 vorname
 nachname
 viertel\_id
 gebaeude\_id

und bei Dir

PERSON
 id
 vorname
 nachname
 gebviertel\_id
 fk\_typ

Wenn Du mir mit diesen Informationen für dein Modell den SELECT hinschreiben kannst, der alle Personen im Gebäude 4711 zurückliefert, dann bist Du ziemlich gut. Ich könnte es nicht. In meinem Modell ist das eher trivial, finde ich zumindest.

Wie kann ich mir die Applikation
vorstellen, die mit dem Datenmodell arbeitet, wie sieht die
Erfassungsmaske aus und wie viel Programmierlogik steck da
drin(kannst du mit APEX eine Enduser-Anwendung generieren oder
muß du da noch Programmieraufwand reingestecken?

Also ich schätze mal grob: Bei mir leichter als bei Dir.

Gruß
Martin

[FrankP]

Hallo Martin,

zum Datenmodell alles Definitionssache. Es kommt einfach auf die Anforderung an. Auf jeden Fall würde ich versuchen Outerjoins zu verhindern. Dein Datenmodell hat mind. einen Fehler, die PLZ kann nicht zum Viertel gehören, da(in Deutschland) nicht mal Strassen die gleiche PLZ haben müssen.

Zum Thema Geschwindigkeit. 6/100 bei einem Durchlauf, lass das mal 100.000 mal passieren, da sind das schon 1,6 Stunden(Bei ner Million Druchläufe = 16h).
Ich habe am Anfang von Sekunden gesprochen, nicht von Stunden… ^^
Wenn das auf einer Produktionsumgebung laufen muss und 100 Leute nicht arbeiten können ergibt das 1600Std. = 1PersonenJahr. Ups…, da sind deine 6/100Sek objektiv sehr teuer(bei 50Euro/h = 80.000Euro).

Dazu kommt noch das deine Applikation viel komplizierter zu programmieren ist(Datenpflege). Und Anforderungen, wie neue Wohnobjekte(Strasse), sind nur durch Datenmodelländerung machbar.

Es muss 'ne bessere Lösung geben, vielleicht ist meine nicht optimal, aber doch schneller und einfacher zu programmieren. Massenänderungen sind viel schneller. Egal wie schön dein Datenmodell ist, es ist zu teuer.

cu Frank

[TheBeast]

Hallo Frank,

zum Datenmodell alles Definitionssache. Es kommt einfach auf
die Anforderung an.

Ja, die kennen wir aber beide nicht, deswegen lässt es sich ja auch so schön theoretisieren.

Auf jeden Fall würde ich versuchen
Outerjoins zu verhindern.

Das wiederholst Du zwar gebetsmühlenartig, richtig wird es dadurch aber immer noch nicht.

Dein Datenmodell hat mind. einen
Fehler, die PLZ kann nicht zum Viertel gehören, da(in
Deutschland) nicht mal Strassen die gleiche PLZ haben müssen.

Mein Datenmodell war der Versuch, da sinnvolle Spalten zu verwenden anstatt col1 bis coln. Damit merkt man dann nämlich auch schon, dass das Deinige - vorsichtig formuliert - seltsam ist.

Zum Thema Geschwindigkeit. 6/100 bei einem
Durchlauf, lass das mal 100.000 mal passieren, da sind das
schon 1,6 Stunden(Bei ner Million Druchläufe = 16h).

Bei einer Million durchläufe braucht dein Datenmodell
0,29s x 1.000.000 = 290.000s = 80h 33’ 20",
das meine braucht
0,35s * 1.000.000 = 350.000s = 97h 13’ 20".
Der Unterschied beträgt also 16h 40 Minuten. Angenommen das sind deine 100 Anwender, und jeder von ihnen macht die (ganz nebenbei so völlig sinnlose) Abfrage täglich zehn Mal, dann brauchen wir für diese Million Abfragen 1000 Arbeitstage, das sind rund 5 Jahre. Wir verlieren also in 5 Jahren 2 Manntage. Ich hoffe nur von den 100 Mannen ist nie einer krank, sonst ist Deine Zeitersparnis beim Teufel…

Ich habe am Anfang von Sekunden gesprochen, nicht von
Stunden… ^^
Wenn das auf einer Produktionsumgebung laufen muss und 100
Leute nicht arbeiten können ergibt das 1600Std. =
1PersonenJahr. Ups…, da sind deine 6/100Sek objektiv
sehr teuer(bei 50Euro/h = 80.000Euro).

Erstens ist - wie soeben gezeigt - dein Ansatz falsch , zweitens dein Ergebnis und drittens ist dein Beispiel-SELECT Blödsinn.

Um auf die 2 Manntage zurückzukommen: Demgegenüber steht ein Angestellter, der das warten muss. Wie schon einmal angefragt: Schreib mir den SELECT hin, der dir alle Personen in Gebäude 4711 liefert. Meiner sieht so aus:

SELECT \* FROM person WHERE gebaeude\_id=4711;

und Deiner? Ich hoffe Du kannst garantieren, dass die Wartung des Programms diese 2 Tage nicht wieder verschlingt. Immerhin arbeitet ja an einem Programm, in dem 100 Anwender werken, normalerweise mehr als ein Programmierer.

Dazu kommt noch das deine Applikation viel komplizierter zu
programmieren ist(Datenpflege). Und Anforderungen, wie neue
Wohnobjekte(Strasse), sind nur durch Datenmodelländerung
machbar.

Noch einmal: Die Zusammenlegung von Viertel und Gebäude stammt von Dir, nicht vom OP. Mit dem gleichen Recht könnte ich also behaupten, es wäre wesentlich sinnvoller, Personen auch noch in die Tabelle reinzunehmen, immerhin brauche ich dann gar keinen Join mehr, was nicht nur schneller als ein Outer Join, sondern zweifelsohne auch schneller als ein Inner Join ist.

Es muss 'ne bessere Lösung geben, vielleicht ist meine nicht
optimal, aber doch schneller und einfacher zu programmieren.

Auch das wieder eine Behauptung, die Du nicht müde wirst zu wiederholen, ohne dass das dadurch richtiger wird.

Massenänderungen sind viel schneller. Egal wie schön dein
Datenmodell ist, es ist zu teuer.

Egal wie schnell Dein Datenmodell ist, es ist falsch und nicht wartbar (und damit zu teuer).

Gruß
Martin

[FrankP]

Hallo Martin,
das ich mich wiederhole liegt einfach da dran, dass du mir nicht das Gegenteil beweisen kannst und du einfach nur falsch liegst.

Bei dem 1Mio updates habe ich eine Massendatenänderung(z.B. während einer Migration) gemeint und nicht den Tagesbetrieb.
Aber auch im Tagesbetrieb sind diese 6/100 nicht zu verachten, wenn du Rechnenleistungs zu verschenken hast, schön(ich nicht).

Mein select würde auch nicht anders aussehen, wieso kommst du auf eine solche Idee?
SELECT * FROM person WHERE wohn_id=4711 (ggf. noch and wohn_typ=‚G‘)
Hier liegst du falsch. Aus meiner Zeit als DatawareHouse-Admin kenne ich fast nur solche Abfragen:

"select person,name,… FROM person p, wohnobject w where p.wohn_id = w.id and w.material in (‚Beton‘,‚Kalksand‘); "

Dort ist niemand auf die Idee gekommen nach ID’s zu fragen.

Wie sieht das Statement bei dir aus? Auf jedenfall wird dein Statement nicht schneller sein als meins, das haben wir mit den 6/100Sek schon bewiesen.
…

Klar im OP ist das Datenmodell vorgegeben worden, das heist aber nicht, das dieses unumstößlich ist (man kann auch mal über den Tellerrand schauen/auch Kunden irren). Also was passiert mit den Strassen? Und wie sehen deine SQL-Statements dann aus? Sind diese dann immer noch 6/100 langsamer, oder sind das schon mehreren Zentel.

Mein Datenmodell besteht aus zwei Tabellen, deins aus drei (mit Strassen 4, mit … 5,…6,…7…8). Wo ist da die Wartbarkeit schlechter?
Du stellst eine Behaubtung auf(die nicht stimmt) ohne diese zu beweisen(weil nicht beweisbar).

Noch mal die Strassen:
Bei mir gibts ein neues Kennzeichen (ggf in einer Kennzeichentabelle) für Strassen und schon können diese erfasst werden.
(da ich von vornherrein schon mit einem Self-Join arbeiten wollte, brauch ich nicht mal Druckprogramme anpassen, diese arbeiten rekursiv ^^)

Bei dir gibts erst mal 'ne neue Tabelle,

• dann müssen alle SQL-Statements angepasst werden(die das alte Datenmodell verwenden),
• dann die Erfassungs- und Abfragemasken für Strassen generiert (und in das Anwendermenü eingebaut werden),
• dann müss die PersonenPflege angepasst werden (neue LOV , neues Feld, neue Label, …)
• hoffentlich müssen wir die Daten nicht im DatawareHouse abfragen, weil wir dann auch noch Schnittstellen anpassen müssen und
• im DWH dann auch noch die Mappings und das Starschema, sowie im Abfrage- und Admintool die Joins.
• boah 5 Personentage?

Deine Behauptung, das dein Datenmodell einfacher(zu warten) ist stimmt nicht.
Es ist der falsche Weg…, aber das werde ich noch viele Male wiederholen müssen bis du das einsiehst. *grins*

cu Frank