Domino 9 und frühere Versionen > ND8: Entwicklung

Prüfroutine um Duplikate zu vermeiden

<< < (2/2)

DerGecko:
Das wäre eine pfiffige Lösung, wenn ich hier irgendeine eindeutige Nummer generieren müßte.

>> Ich möchte aber prüfen, ob die vorgegebene Projektnummer aus der Warenwirtschaft schon vorhanden ist, um dies zu melden und eine Doppelspeicherung zu verhindern:

"Achtung, dein Projekt wurde schon eingetragen - Nummer existiert bereits!"

BigWim:

--- Zitat ---Es muß doch ein gescheites und schon existentes Konzept geben, wie ich Duplikate vermeiden kann...

--- Ende Zitat ---

Ich eine Universallösung wirst Du nicht finden. In Deinem Fall sehe ich zwei mögliche Wege, die aber im gesamten Umfeld betrachtet werden müssen, was von dieser Seite der Tastatur schwierig ist ;)

a) eine zentrale Datenbank, in der Du die Dokumente sammelst und gegen diese DB die Abfrage machst

b) eine ständige Prüfung der Eindeutigkeit mit unterschiedlichen Hinweistexten:
bei Neuanlage: Bereits erfaßt
bei Änderung: Achtung, xy verwendet Ihre Projektnummer. Dokument bis zur Klärung gesperrt

oder so ähnlich

Markus

Peter Klett:

--- Zitat von: DerGecko am 30.06.10 - 11:24:18 ---... manchmal fehlen mir in Notes einfach elementare Funktionen, die in anderen DB Systemen selbstverständliche Boardmittel sind...

--- Ende Zitat ---
Ich kenne kein DB-System, dass an verschiedenen Standorten, oder sogar offline, betrieben werden kann und eine Eindeutigkeit eines Schlüssels ohne vorherigen Datenabgleich garantiert.

Wenn Du die Funktionen solcher Systeme erwartest, musst Du die Datenbank auch so nutzen, wie die anderen Systeme, nämlich zentral auf einem Server.

Bei verteilter Nutzung würde ich die Nummernverwaltung zentralisieren, also eine zentrale DB, in der zu jeder vergebenen Nummer ein Dokument geschrieben wird, gegen diese DB lässt Du die Prüfung laufen. Diese Datenbank kann ganz klein sein, und daher auch bei schlechter Anbindung noch schnell genug (eine Maske, ein Feld, eine Ansicht). Ist diese zentrale Datenbank nicht erreichbar, kann kein neues Dokument erstellt werden. Wobei Du Perfomance sparen kannst, indem Du erst innerhalb der dezentralen Projekte-DB nach der Nummer suchst, ist die dort bereits vorhanden, sparst Du Dir die Suche in der zentralen Nummern-DB.

Vergiss nicht, dass bei Löschungen von Dokumenten auch die zentrale DB aktualisiert werden muss.

Bei fehlender Verbindung der Clients zum zentralen Server wäre auch eine Überprüfung per Mail möglich. Zentral benötigst Du dann eine Mail-In-Datenbank, in die Anfragen zum Vorhandensein der Nummer gesendet werden. Ein Agent in der DB empfängt die angefragte Nummer, sammelt die in einer zentralen Nummerndatenbank und sendet ein OK oder Nicht OK an die dezentrale Mail-In-Datenbank des Standortes zurück, aus dem die Anfrage kommt. Dieses OK oder Nicht OK wird der dezentralen Replik der Projekt-DB in irgendeiner Weise zur Verfügung stellt.

Sollte eine Zentralisierung der Nummernüberprüfung nicht möglich sein, kannst Du die Eindeutigkeit beim Erstellen der Dokumente nicht garantieren, mit keinem System. Da hilft dann nur noch eine nachträgliche Überprüfung, die Dokumente mit doppelt vergebenen Nummern separat ausweist.

pram:
Welche Anforderung hast du denn an die Nummern?

- Wenn die Nummern nicht zwangsläufig fortlaufend sein müssen und Lücken enthalten dürfen
könntest du in Filiale A alle geraden Nummern und in Filiale B alle ungeraden Nummern nehmen.

- ggf kannst du auch irgendwo einen kleinen Webservice ablegen (muss nicht mal unter Notes laufe) bei dem man eine Nummer "ziehen" kann.

Ansonsten, was spricht gegen @unique oder die UNID eines Dokumentes?

Gruß
Roland

Peter Klett:

--- Zitat von: pram am 01.07.10 - 08:39:04 ---Ansonsten, was spricht gegen @unique oder die UNID eines Dokumentes?

--- Ende Zitat ---
Es gibt die Nummern schon in einem anderen System (Warenwirtschaft)

Navigation

[0] Themen-Index

[*] Vorherige Sete