Domino 9 und frühere Versionen > ND7: Entwicklung

"Verkettung" von Formularen

<< < (2/2)

inu:
@MafMetzger:

das mit einer Verkettung hinzubauen ist sich möglich. Ich sehe nur ein Problem, wie ich zum Beispiel eine Ansicht gestalte, in der ich nach Firmen kategorisiert alle Personen aufzeige. Wie könnte ich denn so etwas umsetzen?

Vielen Dank

MadMetzger:
Dann musst du die Daten, nach denen du die Personen kategorisieren willst auch in den Personendokumenten vorhalten (In relationalen DBs müsstest du das nicht, denn dort hast du einen Join zur Verfügung). Das ist die redundante Datenhaltung von der ich sprach.

Wenn du mit Antworten (Firmen = Hauptdokumente, Personen = Antwortdokumente) arbeitest, kannst du auch die Ansicht so gestalten, dass Antworten hierarchisch angezeigt werden, so dass du auch eine Kategorisierung hättest.

Du siehst also, es führen viele Wege nach Rom....  :D

flaite:
Oft wird es so gemacht wie von Markus geschildert.
Im Prinzip kannst du jedes Datenbankmodell mit jedem Datenbanksystem darstellen.
Das Problem ist nur, wie viel Aufwand das macht.
Es ist eine ökonomische Kosten und Nutzen-Frage
Wenn du Teile der Firmendaten auch in den Personen-Daten hälst, ist das ein Fall von doppelter Datenhaltung. Das ist auch kein Drama. Du mußt nur richtig damit umgehen. Es entstehen aber Kosten.

Nehmen wir an du hälst "NameDerFirma" in den Personendaten.
Was ist jetzt, wenn du für eine Firma den "NameDerFirma" ändern willst?
Diese Änderung muss jetzt nicht nur in dem einen Datensatz Firma durchgeführt werden, sondern auch in allen Personendatensätzen, in denen dieser Name auftaucht.
Dies lässt sich im Querysave der Maske "Firma" implementieren.
Weitere Probleme können jetzt aus konkurrierenden Zugriff entstehen.
UserB editiert in einem Dokument eine Telefonnummer und ist ein bischen langsam.
Der deutlich fixere UserA hat kurze später ein Dokument Firma editiert und den Namen geändert. Unglücklicherweise besitzt das von UserB editierte Dokument im Feld "NameDerFirma" genau den Wert, der gerade im Firmendokument von UserA geändert wurde.
Im Querysave der Operation Name der Firma ändern von UserA wird nun - um Inkonsistenzen in den duplizierten Daten zu vermeiden - im Backend das Personendokument gespeichert, das von UserB gerade zum editieren geöffnet ist.
Wenn UserB jetzt das Dokument speichert kommt es zum Speicher-Konflikt.
Es gibt Mechanismen, um solche Probleme abzufangen. Sie sind aber unbestreitbar vorhanden.

Gibt aber auch in Relationalen Datenbanksystemen problematische Hacks, um bestimmte Sachen abzubilden, die in Dokument-Datenbanken wie LotusNotes viel einfacher umgesetzt werden können.
Z.B. der Fall, wenn man zum Zeitpunkt der Tabellen gar nicht weiss, welche Properties ein Datensatz haben soll.

Ist keine Frage von möglich/unmöglich, weil im Prinzip alles möglich ist. Man sollte nur die Beschränkungen (und die Kosten deren Implementierung) kennen, um drumherum programmieren zu können.

Navigation

[0] Themen-Index

[*] Vorherige Sete