"Verkettung" von Formularen

[inu]

Hallo Leute,

ich möchte gern ein Adressbuch erstellen. Hierbei geht es um Firmenkontakte. Selbstverständlich sind mehrere Einträge von Personen ein und derselben Firma denkbar. Ist es ratsam, sowohl die Firmandaten als auch die Personendaten seperat "abzulegen" und dann lediglich die Personendaten mit dem Firmendaten zu "verketten". Ist solch eine Verkettung in Ansichten möglich?

Eigentlich ist dies ein Thema für eine relationale DB...

Vielen Dank

[WernerMo]

Hallo

dazu braucht es keine relationale DB.

Führe einfach ein Feld ein, das für alle Dokomene einer Firma gleich ist, z.b. "Firma" oder "Firmennummer" und nimm dann in der Ansicht dieses Feld als erste Sortierspalte. Innerhalb der Firma kannst Du ja dann wieder nach Typ (z.B. Firma oben, dann Person(en) ... sortieren)

Viele Grüße
Werner

[Driri]

Alternativ kann man dafür auch Haupt- und Antwortdokumente nutzen. Dann hat man die Zuordnung schon vom System.

[WernerMo]

Hallo Diri,

ja und nein, erfahrungsgemäß fusionieren Firmen und andere teilen sich auf, da ist man mit einem extra Feld, das man über einen Agenten (auf markierte Dokumente) noch ändern kann etwas flexibler. Und kann mit entsprechend unterschiedlichen Ansichten auch noch unterschiedliche Sichtweisen darstellen, z.b. nur Personen nach Namen etc.

Viele Grüße
Werner

Übrigens finde ich, dass die Überschrift nicht nur einen hässlichen Tippfehler hat, sondern auch wenig mit dem Thema zu tun hat, und der Autor scheint schon ins "Wochenende" entfleucht" zu sein ?

[MadMetzger]

Aber auch das alles geht eigentlich mit Hilfe von Antwortdokumenten. Die eigentliche Lösung des Problems liegt darin, dass man den Join aus relationalen DBs hier durch redundante Datenhaltung und Verkettung auflösen kann, egal ob über eigene Verknüpfung oder Antwortdokumente.

Also müssen in den Mitarbeiterdokumenten über den Fremdschlüssel(Firmennummer, Hauptdokumentenid oder was auch immer die Firma eindeutig identifiziert) sich die wichtigen Daten beziehen.

Man kann auch die Dokumenten-IDs als Fremdschlüssel verwenden, ohne Antwortdokumente zu nutzen. Dies hat den Charme gegenüber den manuell zu vergebenen Nummern, dass man sich nicht selbst um die Eindeutigkeit der ID kümmern muss, da dies von der Infrastruktur schon sichergestellt ist.

[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.... 

[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.