Has-A vs. Is-A

[Gandhi]

Bin gerade dabei die Datenstruktur für ein Neues Webprojekt mit Domino zu erstellen.
Habe vor dies auch zu Lernzwecken mit 8.5 zu erstellen und ggf. XPages zu nutzen.

Dabei stellt sich mir die Frage, ob es hier sinnvoll ist, die Daten zu "relationalisieren".

Beispiel:
Ich möchte gerne für alle Dokumente einen Historie :-:nabschnitt haben.
Das kann ich über eine Teilmaske lösen.
Aus irgendwelchen Gründen kam mir jedoch dann ein Pattern Buch in den Kopf, in dem es hieß, dass es immer besser sei etwas zu besitzen, als etwas zu erben.
Man könnte auch sagen, dass es besser ist die Datenstruktur zu normalisieren, weil ich derzeit nicht plane die Masken mit eigenständigen Funktionen zu versehen.
Im Konkreten Fall würde dann ein Historiendokument auf ein Dokument verweisen.

Im Notes hatte das bislang immer auch ziemlich gravierende Nachteile.
Nun bin ich mir aber gerade mal nicht so sicher, ob man das noch und auch für Webapplications sagen kann/muss und mein Halbwissen zu XPages (damit habe ich noch rein gar nichts gemacht) macht die Entscheidung nicht einfacher.

Ich stelle daher die Benutzung von Teilmasken in diesem Umfeld (WebApp, Xpages) zur Diskussion:

Ist es in diesem Zusammenhang noch optimal Teilmasken zu verwenden oder sollte man eigenständige Dokumente zu einem Hauptdokument assoziieren?

Aus meiner bisherigen Erfahrung spricht gegen eine solche Assoziierung:
- Viele Dokumente - lahme DB (in dem Fall eher nicht problematisch)
- Links können verloren gehen, wenn sie auf die aktuelle UNID verweisen (leicht zu umgehen, indem man die UNID bei Erstellung nutzt)
- Gleichzeitiges Editieren mehrerer Dokumente kaum möglich (das sollte sich aber mit XPages erledigt haben, wenn ich das richtig verstehe?), sollte auch bei Einsatz von Dojo und Nutzung von Domino ausschließlich als XML Quelle und Senke möglich sein.

Dafür sprechen würde
- Die Komplexität der einzelnen Masken wird reduziert.
- Ich kann auch auf diese Weise in mehreren Ebenen strukturieren (in der Art Teilmaske in Teilmaske)
- Der Code ist besser getrennt - doppelte Feldnamen sind zum Beispiel möglich (z.B. ID)
- 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.


Fazit: Meine Erfahrung sagt mir: Mach das nicht.
Mein Gefühl sagt mir: Das ist viel besser.

Wie denkt Ihr darüber?


Variante 1: Dokument hat Teilmaske Historie
Variante 2: Historiendokument verweist auf Dokument

[WernerMo]

Hallo

mit XPages sollte das egal sein ob V1 oder V2.
Grundsätzlich würde ich Dir aber die Version 8.5.1 empfehlen, wenn Du mit XP beginnst.

Gruß Werner

[ata]

In meinen Datenbanken verwende ich in der Regel die Version 1 - Daten der Historie werden im Dokument gespeichert und nicht extern. Damit kann die Historie nicht verloren gehen, bzw. ist alles vor Ort und muß bei Auswertungen nicht zusammengetragen werden. Nur im Spezialfall würde ich Version 2 wählen.

Toni

[flaite]

Hm. Ich verstehe is-a und has-a völlig anders.
is-a bezieht sich rein auf Vererbungsbeziehungen. Die sollten nicht zu ausufernd sein. Du wirst auch bei komplexen Frameworks selten mehr als 2 Vererbungsebenen unterhalb einer abstrakten Klasse sehen.
Es ist allerdings schon richtig, das man in OO mehr dazu neigt, die Datenstrukturen im Hinblick auf die Menge der Attribute zu verkleinern. Das hat gute Chancen die Übersichtlichkeit zu erhöhen.
In Java würd ich history immer in einer eigenen Klasse definieren und diese Klasse dann irgendwo als Attribut in eine eigene Klasse hängen. Das ist has-a. BUT: Wenn ich die history als zusätliche Attribute in andere Objekte schreiben würde, ohne dass sie durch eine eigene Klasse "zusammengehalten" würden, dann ist das NICHT is-a.

In OO kann man Daten problemlos in so viele Teile zerstückeln wie einem das sinnvoll erscheint. Es existieren keine merklichen physischen Kosten. Objekte leben im Arbeitsspeicher.
Eine Operation

Code

 
myObj.getHistory().getSubject(); 

heißt in Java nichts anderes als:
Suche die Speicheradresse, die in dem Property history von myObj gespeichert ist.
Suche dort die Speicheradresse des property subject und gebe dieses zurück (es ist ein Objekt vom Typ java.lang.String)
Im Arbeitsspeicher läuft das alles rasend schnell.
Es beansprucht vom Rechner nicht viel mehr Arbeit als:

Code

myObj.getHistorySubject(); 

Hier spart man die Suche der Speicheradresse des Objekts des Typs History. Diese Operation ist aber nicht kostspielig.
Das sieht anders aus, wenn man sich wie in Notes die Daten erstmal von Platte holt. Da bedeutet die Suche und das Lesen von history (also der Zwischenschritt) deutlich kostspieligere IO Operationen.

Heute abend folgt noch eine Anekdote, warum das in RDBMS Sinn machen könnte, die History in einer eigenen Tabelle abzuspeichern. RDBMS ist aber nicht OO.

Design Pattern Bücher enthalten keine Regeln, wie man zu programmieren hat. Patterns sind solutions in a context. Dies drückt bereits aus, dass die Anwendung eines Patterns oder einer Design-Best-Practice wie has-a oft besser als is-a immer eben auch kontextabhängig ist.

Aber wie gesagt: Mit is-a hat das ganze null zu tun.

[Gandhi]

Ja, der Titel ist 'misleading'
Aber diese Patterngeschichte (auch wenn es nicht is-a ist) hat mich auf den Gedanken gebracht, der tatsächlich eher auf Normalisierung als auf Vererbung (was ich damit meine ist die Teilmaske, die sehr Abstrakt und aus meiner Sicht eine Art Vererbung ist, da die Maske von der Teilmaske Attribute und Methoden 'erbt' - wenn auch andere OO Features natürlich nicht umgesetzt werden können) abzielt.
Insofern ist der Titel nicht so gut gewählt.

Dennoch bleibt für mich die Frage, wie das optimal zu lösen ist. Sind Teilmasken nocht Mittel der Wahl oder verknüpfe ich besser Dokumente miteinander. Also: Erstelle ich da eine Relation (Ja, Notes ist keien Relationale DB - aber das heißt ja nicht, dass man keine Relation erstellen kann). Und wenn ja: Was spricht dafür und was dagegen.

[flaite]

Ok. Du kennst meinen Diskussionsstil  
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.