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

[Basti07]

>> Ups..., gehört doch eher in "Entwicklung" und nicht hier rein.


Hallo zusammen,

ich bin an der Entwicklung einer Projekt-Daba und habe leider zu meinem Problem auf atnotes leider nichts gefunden.

Zunächst einmal zum Momentanen Sachlage:

In der Daba gibt es eine Projektmaske mit einem beim Anlegen berechnetem Feld "Projektnummer". Wiederum ist die Projektmaske mit Leser- und Autorenfelder ausgestattet.

Das Ermitteln der nächsten Projektnummer in der Projektmaske erfolgt mit folgender Formel fehlerfrei:

PJNummern := @DbColumn("":"NoCache";"";"View_P_NR";1);
PJMaxNummer := @Subset(PJNummern;1);

@If(PJNummern = ""; 1; PJMaxNummer + 1)

Die o.g. VIEW (View_P_NR) enthält "eine" Spalte mit dem Wert Projektnummer aus jedem angelegtem Projekt und ist absteigend nach der Projektnummer sortiert.

Jetzt zum eigentlichen Problem in Kombination mit Leser- und Autorenfelder:

- Der Benutzer XXX erstellt ein neues Projekt. Automatisch wird die Nummer '1' vergeben. Zusätzlich beschränkt XXX den Lese- und Schreibzugriff auf sich selbst.

- Zu einem späteren Zeitpunkt erstellt Benutzer YYY ein neues Projekt. (Nun sollte dafür ja eigentlich die Projektnummer '2' vergeben werden). Bei der Anlage wird nun aber die Projektnummer '1' vergeben...das sollte natürlich nicht passieren!!!

Die Ursache dafür war mir ziemlich schnell klar. Denn in der VIEW (View_P_NR) ist für den Benutzer YYY das von Benutzer XXX angelegte Projekt nicht sichtbar, weil dieser den Zugriff auf das Dokument geschützt hat.

Habt Ihr eine Idee wie ich z.B. in der VIEW trotz des Dokumentenschutzes den Wert für jeden angezeigt bekommen kann? Oder soll ich einen ganz anderen Weg fahren?!

Bin für jeden Ratschlag dankbar.

Gruß, Basti07

[Glombi]

Hallo und willkommen im Forum.

Bevor jetzt hier gleich alle anfagen zu toben - bitte benutze mal die Forumssuche. 

Es gibt da einige Threads zu laufenden Nummern.

Andreas

[m3]

Das Thema "fortlaufende Nummer" hatten wir schon öfter und eine Suche nach diesem Begriff in diesem Forum sollte Dir alle relevanten Informationen liefern.

Dein "Problem", dass die Nummerierung aufgrund der Leseberechtigungen nicht stimmt, ist nur ein kleiner Teilaspekt der "ich schau in einer View nach, welche Nummer als nächste kommt" Problematik. Stichwörter über die Du in diesem Zusammenhang nachdenken solltest: Repliken, Offline-Verwendung der DB, Atomarität, ...

[flaite]

Sind Nummern überhaupt brauchbare Bezeichner für Projekte?
Gut. Man kann mit Nummern sotieren. Aber das geht auch über das Anlege-Datum des Projekts.
Nimm doch einfach den Namen des Projekts als Schlüssel. Beim Speichern überprüfst du einfach, ob der Name bereits  existiert. Falls ja, soll der Projekt-Anleger einen anderen Namen wählen.
Vor der Zeit des knappen Speicherraums (Steinzeit bis 60er Jahre) wurden nämlich Dinge fast nie mit Zahlen oder irgendwelchen fixed-length Strings versehen. Zugegeben vielleicht im naturwissenschaftlichen Bereich manchmal schon (Periodensystem der Elemente). Aber sonst? Heissen unsere Städte vielleicht D-1, D-4, D-5, Bo-1. Oder doch eher Köln, Nürnberg, München, Dresden, Potosí?
Steckt da nicht vielleicht ein tieferer antroposophischer Sinn hinter. Dass sich nämlich das menschliche Hirn besser Folgen von Konsonanten und Vokale mit Dingen verknüpfen kann als irgendwelche Zahlen oder Buchstabenkombinationen wie 003_CB_134234, 14 oder 192.168.1.36

Ich habe solche Diskussionen jetzt, 2007 Jahre p. Chr., in Webservice Projekten.
Jemand: Wir nummerieren die Fehler durch. Nummer 1 heisst: Der Vorgang ist bereits angelegt. Nummer 2 heisst: Es gab ein Verbindungsproblem mit dem Server. Nummer 3 heisst Daten fehlen.
Ich (denke): Oh nein. Nicht schon wieder. Es scheint Spaß zu machen in einem Excel Sheet Zahlen zu schreiben und denen Nachrichten zuzuordnen.
Ich: Und wie sollen die Administratoren wissen, was das bedeutet?
Jemand: Die sollen in der Dokumentation nachschlagen.
Ich: Und wieso geben wir das nicht einfach Klartext in englischer Sprache aus: A Request Discount for this offer allready exists, Cannot connect to the server, The message should contain the field "xxx"
Jemand: Sind Nummern nicht effizienter?
Ich: Nein. Das heisst vielleicht. Aber auf jeden Fall nicht merkbar. Die Vorteile bewegen sich im Tausendstel Millisekundenbereich. Und wir respektieren das Menschenrecht von Administratoren möglichst wenig in irgendwelchen voll langweilig geschriebenen Dokumentationen nachzuschlagen.

Der Grund warum Nummern eine so große Rolle spielen ist, dass
a) früher Speicher wirklich sehr teuer war und
b) Relationale Datenbanken mit Zahlen als primary und foreign keys tatsächlich deutlich schneller arbeiten können.

Deshalb benutzen von mir angelegte Relationalen Datenbanken für Primär- und Fremdschlüssel grundsätzlich integer oder bigint. Aber überall anders macht das heute praktisch fast nie Sinn.

[cash]

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

[m3]

... oder auf verschiedenen Servern oder offline arbeiten, oder ...


Die Diskussion hatten wir nun schon wirklich 100.000 fach.

Danke,  bitte schließen.

[jo@chim]

Auch wenn in der Tat schon einiges zum Nummernproblem gesagt wurde - Axels Argumentation kann ich so nicht nachvollziehen:

Aber sonst? Heissen unsere Städte vielleicht D-1, D-4, D-5, Bo-1. Oder doch eher Köln, Nürnberg, München, Dresden, Potosí?

Lautet Deine Telefonnummer vielleicht AxelJanssenWoauchimmerWaldstrasse12 oder Dein KFZ-Kennzeichen SchönerGelberPorscheVonAxelJanssenAusWoauchimmer?

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

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.
Für lesegeschützte Dokumente wird ebenfalls eine neue ID auf dem "Nummernserver" angelegt (mehr nicht), so dass die fortlaufenden Nummern hochgezählt werden können.

[MadMetzger]

Also bei Nummernsystemen sollte bei jedem Entwickler eine Alarmglocke schrillen... Bei Nummernsystemen meint man ja in der Regel, dass einem Schlüssel für zB ein Dokument eine Bedeutung innewohnt. Also könnte man in solchen Fällen von einem sprechenden Schlüssel reden. Aber diese wiederum sind nicht gut, da die Information dadurch redundant vorgehalten wird, nämlich einmal im Schlüssel und einmal in dem eigentlichen Dokument. Was aber nun, wenn sich was an den schlüsselrelevanten Eigenschaften ändert? Dann ist die Information aus dem Schlüssel nichts mehr wert... Außerdem hat man sog. sprechenden Schlüsseln auch noch weitere Probleme, zB. dass man sich selbst in den Schlüsseln beschränkt und hier dann immer wieder das System anpassen muss, um Platz für neue Datensätze oder ähnliches zu erhalten.

[jo@chim]

Bezüglich der "Alarmglocken" stimme ich Dir (unabhängig davon, dass man immer über die Konsequenzen von Anwenderwünschen nachdenken sollte) zu. Aber:
Telefonnummern waren früher auch "sprechend" (Hinweis auf den Standort des Anrufers innerhalb des Vorwahlbereiches, zumindest für die die den Schlüssel defchiffrieren konnten) - das interessiert aber im Zeitalter des Mobilfunks niemand mehr. Trotzdem kommt niemand auf die Idee, die Nummern abzuschaffen.
Wenn Auftraggeber Nummern "mit Bedeutung" wollen, sollte man ihnen das in der Tat ausreden. ID's, die der schnelleren Auffindbarkeit dienen, haben aber oft durchaus ihren Sinn.

[MadMetzger]

IDs dienen der reinen Identifikation eines Datensatzes und für mehr dürfen sie nicht gut sein, sprich weitere Informationen sollte man nicht herausziehen können. Ein gutes DV-System kann logischerweise nach allen wichtigen Kriterien suchen. Die sprechenden Schlüssel stammen eigentlich noch aus der Zeit der "Papierordner", die man mit Hilfe der Schlüssel schneller durchsuchen kann. Ansonsten unterstützt sogar eine rein fortlaufende Nummerierung bei der Suche,  dafür ist kein sprechender Schlüssel erforderlich.

[flaite]

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

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.

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.

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.

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.

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)

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)

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

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]

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

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

[Basti07]

Hallo Ihr,

mittlerweile habe ich mein sog. 'Problem' doch lösen können und ähnlich wie "Cash" schon beschrieben hat, per Profildok gelöst. Da ich im Thema Notes-Entwicklung noch recht am Anfang stehe, sind mir selbstverständlicher Weise noch nicht sehr viele Möglichkeiten bekannt. Nachdem ich mich aber hier im Forum auf die Suche nach Profildokumenten gemacht habe, bin ich doch schnell fündig geworden...und auch die Notes-Hilfe ist diesbzgl ein Blick wert. Das ganze funktioniert mittlerweile auch sehr sauber und die User haben auch noch nicht gemeckert  ...deshalb verstehe ich auch nicht die Aussage von Dir Bernhard:

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.

...Das Prinzip funktioniert und wurde sicher nicht nur einmal getestet...Ich denke auch das diese gewählte Variante für unseren Bedarf vollkommend ausreicht. Es muss keine Anwendung für den großen Markt entwickelt werden, sondern lediglich für den Eigenbedarf oder für ein kleines Unternehmen mit 'hier' und 'da' mal ein Projekt...Und zur Frage "warum überhaupt eine Nummer" kann ich ganz einfach beantworten...In der Ansicht kommen Nummern als zusätzlicher Präfix einfach besser zur Geltung auch wenn das vielleicht (kann ich auch wiederum verstehen) nicht undbedingt notwendig ist.

Gruß, Basti07

[m3]

Hallo Ihr,

mittlerweile habe ich mein sog. 'Problem' doch lösen können und ähnlich wie "Cash" schon beschrieben hat, per Profildok gelöst. Da ich im Thema Notes-Entwicklung noch recht am Anfang stehe, sind mir selbstverständlicher Weise noch nicht sehr viele Möglichkeiten bekannt. Nachdem ich mich aber hier im Forum auf die Suche nach Profildokumenten gemacht habe, bin ich doch schnell fündig geworden...und auch die Notes-Hilfe ist diesbzgl ein Blick wert. Das ganze funktioniert mittlerweile auch sehr sauber und die User haben auch noch nicht gemeckert 

NOCH.

Wie Glombi so schön geschrieben hat:

Profildokument sind
- schnell da im Cache
- u.U. unbrauchbar da im Cache

Also: Diese nur verwenden, wenn deren Inhalt sich innerhalb einer Session nicht ändert.

Auch Gulliver hatte dazu schon etwas zu sagen:

Genau diese Überlegungen habe ich auch angestellt, um einen Mechanismus zu bekommen, der mir Fortlaufende Nummern erzeugt.

Das mit dem Profildokument ist keine gute Idee und funktioniert auch nur im Single-User-Betrieb. Ein Profildokument wird für den schnellen Zugriff ge-cached und nicht sofort zurückgeschrieben (erst beim beenden der Sitzung).

Probier das empfohlene Beispiel mal an mehreren Stationen und Du wirst sehen, dass diese die Nummern paralell hochzählen.

[jo@chim]

Aber in einem Notes System neige ich eher dazu Daten "einfach" redundant zu halten.

Schon richtig Axel, ich ja auch - es kommt wohl immer darauf an, um welche Anwendung es geht: wenn ich ein Diskussionsforum entwickle, sind Nummern sicher deplatziert. Bei einer Helpdeskanwendung sollte man über schnelle Identifizierung per Ticket schon nachdenken. Und für ein Auditmanagementsystem benötige ich unbedingt eindeutige Auditnummern, da die Norm dies vorschreibt.
Aus diesem Grund zieht übrigens (leider) der Hinweis auf die UNIDs nicht: die Auditoren wären z.B. über eine 32-stellige Auditnummer nicht sehr begeistert
Manche Diskussionen kommen, so unangenehm uns das sein mag, aufgrund realer Anwenderbedürfnisse - sind das nicht die komischen Leute, die direkt oder indirekt unsere Brötchen bezahlen? - immer wieder hoch. Einfache "Patent"-Lösungen ziehen da nicht, imho. Ich denke, ein "Nummern How-to" (das natürlich auch ein "When-do" sein sollte) ist deshalb wirklich eine gute Idee.

[flaite]

Damit wäre die Diskussion beschränkt auf einen relativ eingrenzbaren Business Case, der bei weitem nicht in jedem Notes Projekt auf der Agenda steht. Gerade viele Anfänger glauben aber, dass sie für jeden Dokumenttyp eine eindeutige Nummerierung der Dokumente bräuchten. Aus meiner Sicht ist das anders als bei RDBMS. In RDBMS ist es eine Ausnahme für eine Relation, keine künstlich erzeugte eindeutige Nummer zu benötigen, die für die Business Sicht auf die Daten keine Bedeutung hat. In Notes ist es eher eine Ausnahme. Für bestimmte Business Cases (Auditoren-Nummern) benötigt man das unbedingt. In anderen Fällen hat es Vor- und Nachteile und in vielen Fällen hat es mehr Nach- als Vorteile.

[jo@chim]

D'accord. Übrigens neige ich aus dem Grund auch dazu, in relationalen Systemen Unique IDs zu "verstecken", falls sie für den Anwendungszweck nicht benötigt werden.