Domino 9 und frühere Versionen > ND6: Entwicklung

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

<< < (2/6) > >>

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:


--- Zitat ---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í?

--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete