Best Practices > Diskussionen zu Best Practices

Has-A vs. Is-A

<< < (2/2)

flaite:
Ok. Du kennst meinen Diskussionsstil  ;D
Ich stimme dir nicht einmal auf der Ebene der Begrifflichkeiten zu.
Eine Maske mit Teilmasken seh ich eher als eine Design-Time Komposition.
Die Gesamtmaske setzt sich aus einer Maske und aus 0...n Teilmasken zusammen. Das ist eine has-a Beziehung, keine is-a.
is-a Beziehungen sind gerichtete Beziehungen, in der nach unten hin immer mehr spezialisiert wird.
Ein Auto ist-ein Vehikel.
Ein ISO8061DateFormatter is-a BaseFormatter (realistisches Beispiel für Vererbung).

Aber ein UnternehmensDok is-a History?
UnternehmensDok ist keine Spezialisierung von History, selbst wenn es eine History Teilmaske enthält.
Wie gesagt: Masken-Teilmasken Beziehungen ist für mich eine Art Design-Time Komposition.

Über-Normalisierung kann in RDBMS auch zu einem Fluch werden.
In Notes sind joins schon deshalb problematisch, weil sich bei einer Kopie der Datenbank die UniqueIDs ändern.
 

Gandhi:
:-)
ich weiß, das ich wahrscheinlich vollkommen Unrecht habe - höre aber einfach nicht auf zu diskutieren (das gehört zu meinem Lernstil - man hat mich auch schonmal als ungläubigen Thomas bezeichnet - aber was ich nicht vollständig verstehe verstehe ich gar nicht)

In der Schweiz gab es mal einen Slogan der SBB, in der es folgenden Satz über Züge zu vervollständigen gab:
"Ich bin auch ein ..."

Im Rahmen von Mehrfachvererbung (was OO aber nicht Java ist - was wiederum aber nicht alleinig und selbst OO ist) ist es imho schon so zu betrachten, dass ein Dokument auch ein History-Dokument ein Header-Dokument und ein XYZ-Dokument ist, weil es von allen diesen Teilmasken sovohl "Properties" als auch "Methods" besitzt.

Das ist natürlich mehr als Abstrakt und natürlich gibt es (leider, leider) keine Spezialisierung/Polymorphismus etc. - aber es geht ja auch um eine sehr abstrakte Betrachtung. Und da meine ich muss man den OO Begriff nicht mal so fürchterlich weit schleifen um drüber nachzudenken, ob der Ansatz auch hier was bringt.

Wegen der Normalisierung:
Ich habe mir zur Gewohnheit gemacht NIE auf die UNID bei Referenzen zu bauen - sondern baue mir ein eigenes ID Feld - in das ich meistens (computed when composed mäßig) die erste ID speichere, die dieser Datensatz (womit ich nicht das Dokument, sondern die Datenrepräsentation meine) je hatte.
Insofern ist es mir dann auch egal, ob das Dokument oder die Datenbank je kopiert werden, weil meine Schlüssel davon nicht abhängen.

Ansonsten will ich auch nichts übernormalisieren - sondern nur normalisieren - bzw. einer Normalisierung näher kommen - weil man es somit aus meiner Sicht leichter hat mehrfache Datenobjekte an ein Datenobjekt anzuschließen (z.B. Transaktionen, die an einem Dokument vorgenommen wurden).
Das kann man zwar auch mit Feldern machen - ist aber meistens kompliziert - schwer in der Anzeige umzusetzen und vor allem sehr schlecht auswertbar.

Ob das geht - klar - mache ich fast ständig wenn Bedarf daran besteht.
Die eigentliche Frage ist also, wie weit man das Spiel spielen sollte/kann - gerade in Verbindung mit neuen Technologien wie XPages.

flaite:
Naja. Du machst einen Satz, der als weiche Beschreibung einer Tendenz intendiert war (prefer composition over inheritance) zu einer Art Axiom.
Ein Thema von dem ich besessen bin. Diese Theoriewelten müssen mit einem höchsten Grad an Bescheidenheit behandelt werden. Kann da nicht einfach glitzernde Glassteine aus dem Kontext reissen und zu einer eigenen von "wissenschaftlichen Autoritäten" unterfütterten Theorie zusammenpuzzeln.

Von den ausgehenden Argumenten überzeugen mich mehr die dagegen.

Aus meiner bisherigen Erfahrung spricht gegen eine solche Assoziierung:
- Viele Dokumente - lahme DB (in dem Fall eher nicht problematisch)
Kann aber problematisch werden, wenn die Datenbank wächst.

- Links können verloren gehen, wenn sie auf die aktuelle UNID verweisen (leicht zu umgehen, indem man die UNID bei Erstellung nutzt)
Dann erzeugt man aber das Risiko duplizierter "Primärschlüssel", wenn die Anwender Replizierung verwenden (das Thema hatten wir öfters).


Dafür sprechen würde
- Die Komplexität der einzelnen Masken wird reduziert.
Bei Teilmasken eher nicht. Ist ja eine Design-Time Composition.
- Ich kann auch auf diese Weise in mehreren Ebenen strukturieren (in der Art Teilmaske in Teilmaske)
Man kann ja auch verschiedene History Teilmasken erstellen.
- Der Code ist besser getrennt - doppelte Feldnamen sind zum Beispiel möglich (z.B. ID)
Kann man mit Präfixen bei der Benamsung ausschliessen. Alle history-Felder erhalten ein Präfix hist_
- Unterschiedliche Bereiche können von verschiedenen Personen gleichzeitig editiert werden, da es sich dann um faktisch separate Dokumente handelt, die nur als ein Dokument angezeigt werden (ist für das Historiendokument nicht sooo wichtig - in einer weiteren Ebene könnte man dann aber noch die durchgeführten Transaktionen {Feldname;Altwert;Neuwert} auf diese Weise Abstrahieren.
Ist bei Historien-Feldern eher irrelevant, weil diese praktisch immer automatisiert von irgendeinem Code im querySave gesetzt werden.

Navigation

[0] Themen-Index

[*] Vorherige Sete