Domino 9 und frühere Versionen > ND6: Entwicklung

Dokumente mit fortl. Nummer in Kombination mit Lesern- und Autoren

<< < (3/6) > >>

flaite:

--- Zitat von: jo@chim am 23.04.07 - 12:18:34 ---Es gibt über die Notwendigkeit Speicherplatz zu sparen oder die Anwendungsgeschwindkeit hinaus in der Praxis sehr wohl weitere triftige Gründe, in einer Anwendung ein Nummernsystem zu verwenden. Z. B. zur schnellen Identifizierung von Dokumenten im Telefongespräch o.ä.

--- Ende Zitat ---
Als Primär- oder Fremdschlüssel in RDBMS bin ich ein Verfechter von integer und bigint. Aber in Lotus Notes bringt es dir einfach keine oder nicht merkbare Vorteile, ob du aa oder 11 verwendest. In Notes wie übrigens auch in allen Anwendungen von xml als Datenspeicher bringen Zahlen keine merkbaren Performance-Vorteile.

--- Zitat ---Darüber hinaus haben Bezeichnungen von Dokumenten die unangenehme Eigenschaft, dass sie dem Anwender spätestens am nächsten Tag unpassend erscheinen und dringend geändert werden möchten.

Nein, das "Nummernproblem" lässt sich nicht umgehen in Notes, IMHO.

--- Ende Zitat ---
Das ist eine ganz andere Frage. Wenn ich wirklich einen eindeutigen, unveränderbaren key in einer Lotus Notes Datenbank benötige, würde ich zuerst mein Augenmerk auf die DocumentUniqueID legen. Die ist nämlich vom System generiert.


--- Zitat ---Wir gehen das bei diversen Anwendungen (über diverse internationale Server replizierend, mit lesegeschützten Dokumenten ...) per "Nummernserver" an: Auf einem zentralen Server liegt eine separate Datenbank, die die Nummernkreise verschiedener Anwendungen verwaltet. Ist diese DB nicht erreichbar (z.B. weil der Anwender lokal ohne Netzwerkverbindung arbeitet), können Dokumente nur als "Entwürfe" angelegt werden, die entsprechend in einem privaten Entwurfsordner der Anwender abgelegt werden.

--- Ende Zitat ---
Bringt das echt so viele Vorteile? Zumindest ist es ein single point of failure. Warum so kompliziert und nicht einfach die eindeutige vom System bereits generierte DocumentUniqueID verwenden. Oder eben "Business Keys" in den Dokumenten. Natürlich kann es Probleme geben, wenn die "mutable", d.h. editierbar, sind. Aber eure magischen Nummern vom Nummernserver lassen sich zumindest von einer böswilligen Person mit Autor-Rechten auf das Dokument ändern. Ausser der DocumentUniqueID ist nämlich alles in einem Notes-System per Agent mutable.

Ich hab genug große und erfolgreiche Notes-Installationen gesehen, die gut ohne einen solchen "Nummern-Server" auskommen.

In Postgresql, db2, mysql kenne ich vielleicht 10 verschiedene Arten, um eindeutige Keys zu generieren (Sequence, eigene Tabelle, Identity column, aus J2EE Patterns Buch von theserverside.com abgetippter Algorythmus der Zeit und MAC-Adresse des Rechners benutzt, etc.)
In Notes braucht man das imho nicht so oft.
Aber vielleicht können wir uns einfach darauf einigen, dass wir darin übereinstimmen, das wir nicht übereinstimmen.  ;)

flaite:
Aus meiner Sicht, werfen wir hier 2 oder Diskussionen durcheinander.
Markus Einwände sind natürlich richtig und da hab ich mich oben falsch, d.h. irreführend ausgedrückt.
"Sprechender Schlüssel" wird in der Datenbanktheorie (zumindest die ich lese) als "Business Key" bezeichnet. D.h. ein Schlüssel, der in dem abzubildenden Business Case eine Bedeutung hat. Die Verwendung von solchen keys ist selbstverständlich problematischer als von mir oben dargestellt. Sowas ist aber gut in Ansichten. Die wirklichen Verlinkungen zwischen Dokumenten/Datensätzen sollten aber meist wirklich durch einen "natural key" dargestellt werden. Also etwas, das beim Anlegen des Dokuments erzeugt wird und nicht-änderbar ist. Dafür kann man aber imho in Notes-Systemen sehr oft die DocumentUniqueID verwenden. In Ansichten macht die sich natürlich nicht besonders gut. Frag mich aber, ob ein eigener "Eindeutige Nummer Service" wirklich bessere Ergebnisse erzielt.

MadMetzger:
Das ist richtig, was du sagst, Axel. Ich sprach auch nur auf das Nummernsystem an, welches du meinst. Ich persönlich verwende in einer Anwendung in Notes von mir als Schlüssel eben auch die DocumentUniqueID, welches dort zum Referenzieren das Optimum darstellt, wie ich es finde.
Ansonsten sind diese Business Keys in meinen Augen aber nicht wirklich gut, weil es eben ein doppeltes Ablegen von Daten ist. Der Vorteil von Ansichten ist, finde ich, nicht wirklich gegeben, weil man gerade hier auch auf die tatsächlichen Daten referenzieren kann. Außer man berechnet den Schlüssel aus den tatsächlichen Daten und hält ihn nicht persistent.

flaite:
Ist schon richtig, dass Business Keys nicht gut sind. Deshalb sind meine obigen Aussagen auch nicht besonders sinnvoll.
Wenn man z.B. über den Projektnamen beteiligte Dokumente verlinkt. Und der Projektname umbenannt wird, dann müssen alle untergeordneten Dokumente, die das Feld "Projektname" irgendwo als Fremdschlüssel benutzen auch geändert werden. Und das führt natürlich direkt zu Speicher- und Replizierkonflikten.
In Notes hat man aber grundsätzlich weniger Schlüssel als in RDBMS, weil es eben für solche Beziehungsgeschichten zwischen Dokumenten Spezialfelder gibt. Für Fremdschlüssel kann man auch $Ref nehmen. Also Antwort-Dokumente. In RDBMS hab ich aber Tabellen, die fast nur aus irgendwo automatisch generierten Schlüsseln bestehen. In Notes ist das "weniger".

Beispiel:

--- Code: ---
fussi=# select * from offerstock;
 id  | iduser | idstock | amount | price |        creation
-----+--------+---------+--------+-------+-------------------------
 265 |    251 |      23 |      1 | 25.00 | 2007-04-21 16:51:30.265
 271 |    237 |      25 |     20 | 25.00 | 2007-04-22 21:43:20.14
(2 Zeilen)

--- Ende Code ---
Mit "aufgelösten" Fremdschlüsseln:

--- Code: ---fussi=# select offerstock.id, "user".name, stock.name, offerstock.amount, offerstock.price from offerstock, "user", stock where offerstock.
duser= "user".id AND offerstock.idstock = stock.id;
 id  | name  |  name   | amount | price
-----+-------+---------+--------+-------
 265 | Axel  | Chile   |      1 | 25.00
 271 | Axel1 | Uruguay |     20 | 25.00
(2 Zeilen)

--- Ende Code ---

RDBMS Tabellen Bezeichner wie user zu geben ist ein Zeichen von robusten Nerven.  ;D

Leute mit starken RDBMS Hintergrund überschätzen leicht die Bedeutung von automatisch generierten Keys in Notes. Zumindest wurde mir das über Jahre erzählt. Bin noch nicht mal 100% sicher, ob das überhaupt stimmt.

Hätte ich das in Notes gemacht, gäbs für die Referenzen auf "Dokumente" des Typs User oder Stock nicht diese automatisch generierten Nummernschlüssel. Ich hätte das irgendwie anders gelöst. Z.B. in für offerstock User und Stock den Namen direkt in die Offerstock Dokumente geschrieben und diese Felder in User und Stock unveränderlich gemacht (zB. erzeugt beim Anlegen). Vielleicht noch ein Feld "DisplayStockName" oder "DisplayUserName" die frei veränderlich sind.
Man kann natürlich auch die jeweiligen DocumentUniqueIDs von User und Stock in Offerstock schreiben und die Informationen jeweils per DBLookup einladen. Da ist der Geschwindigkeitsverlust aber vergleichsweise höher als bei joins in RDBMS. Und es hat den Nachteil, dass man die Daten so einer xTreme DocumentUniqueID verpointerte Notes Datenbank nicht mehr kopieren sondern nur noch replizieren kann.

Wenn es jetzt einen Service gibt, der solche Keys automatisch erzeugt (wie von jo@chim beschrieben) verwendet man das vielleicht häufiger. Neben den Nachteilen (single point of failure, Netzwerk Latenz, so ganz transparent ist das mit den "Entwürfen" für die Anwender vielleicht auch nicht) hat das auch Vorteile. Aber in einem Notes System neige ich eher dazu Daten "einfach" redundant zu halten. Und das hat natürlich wieder Nachteile, falls jemand umbenennen will.

koehlerbv:

--- Zitat von: cash am 23.04.07 - 11:38:44 ---habe auch eine Datenbank mit Nummern. Ich hole die Zahl von einem normalen Dokuemtn was ich als Profildokument nutze. Erst wenn der User "Speichern" klickt (alle anderen Arten von Speichern habe ich unterdrückt) wird im aktuellen Dokument die Nummer vom Profildokument geholt plus 1 addiert und in das Feld Nummer geschrieben und dann sofort das Feld im Profildokument ebenfalls um 1 erhöt. So klappt das bei uns ganz gut. Problem kann so nur auftreten wenn wirklich 2 Leute zu gleichen Zeit bei unterschiedlichen Dokumenten "Speichern" drücken...

Cash

--- Ende Zitat ---

Jetzt geht doch wieder die Debatte "ich habe keine Ahnung, brauche aber fortlaufende Nummern" erneut los. Aber es ist ja auch ein Dauerbrenner, und dies nicht ohne Grund.

Vorab zu "Cash", oder wie immer er heisst: Martin hat schon das richtige geschrieben - das kann nicht funktionieren. Und wenn wir bei Alarmglocjken sind, dann läuten diese bei mir, wenn jemand schreibt "klappt das bei uns ganz gut". Konjunktiv? Klar! Es funktioniert, oder es funktioniert nicht - und das ganze robust geprüft! Und dieses Prinzip kann nicht "klappen" - das ist genau das, was man niemals machen darf.
Den Begriff "Profildokument" würde ich auch gern hinterfragen: Handelt es sich beim Nummern-hochzählenden Dokument wirklich NICHT um ein ProfileDocument? Letzteres funktioniert nun nämlich nun gar nicht. Aber siehe Suche ...

Ich hatte heute gerade Projektverhandlungen bei einem Kunden, der tatsächlich eine fortlaufende Nummer aus einem Notes-Dokument (welches dann in ein relationales System übergeben wird und dort / dorthin referenziert werden muss) benötigt. Die Fälle gibt es ja nun wirklich, und Notes-interne übliche Verfahren helfen uns dann nicht weiter. "Tipps" wie man sie auch bei AtNotes auffindbar sind auch aber auch nicht.

Das ganze ist nun wirklich mittlerweile einen AtNotes-BP-Artikel wert:
- Wann kann man "fortlaufende Nummern" wirklich vermeiden
- Wenn man sie braucht: Was ist erforderlich
- und all die Dinge, die nur Schrott sind ("Cash" setzt vermutlich soetwas ein
- und ein endloses, ständig zu vervollständiges Kapitel: In welcher Situation setzt man welches Verfahren ein?

Vulgo: Wir haben die alte Debatte nun doch wieder am Hals, und wir sollten uns dieser stellen (wenn man denn KnowHow teilen mag).

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete