Domino 9 und frühere Versionen > ND8: Entwicklung

Optimierung einer Suchfunktion

(1/3) > >>

Keydins:
Hallo zusammen,

ich bin auf der Suche nach einer Möglichkeit zur Optimierung einer Dokumentensuchfunktion in einer Anwendung, die wir seit ca. 10 Jahren einsetzen. Die Anwendung wurde nicht von uns entwickelt sondern extern zugekauft, allerdings mit offenem Design, so dass ich Anpassungen vornehmen kann.

Hintergrund ist der, dass sich unsere Anwender in letzter Zeit darüber beschweren, dass die Anlage von neuen Einträgen in der Anwendung extrem lange dauert (früher: ca. 10 Sekunden, jetzt ca. 90 Sekunden). Die aktuellen Zeiten kann ich bestätigen, bei den 'früher' Angaben verlasse ich mich darauf, dass sie kurz genug waren, dass die Anwender sie als akzeptabel betrachtet haben.

Die Anwendung ist ein Verzeichnis für die Ablage von Offlineakten (-> Papier) und umfasst inzwischen ca. 50.000 Dokumente. Pro Jahrgang kommen aktuell ca. 2.500 dazu.

In den Dokumenten wird das gewünschte Archivierungsjahr aus einer Dropdownliste gewählt. Beim Speichern wird die zu vergebende fortlaufende Nummer automatisch über eine Ansicht ermittelt. In der Ansicht sind alle Dokumente aufteigend nach dem gewählten Jahr sortiert, so dass bei neuen Dokumenten des aktuellen Jahrs sehr schnell die nächste laufende Nummer ermittelt werden kann (->view.GetLastDocument). Die Nummern sind immer 5-stellig mit führenden Nullen und werden aus diesem Grund als Text im Dokument gespeichert.

Die Anwendung ruft im QuerySave eine Prüffunktion auf, die sicherstellen soll, dass keine doppelten Nummern vergeben werden. Dazu wird die laufende Nummer des aktuellen Dokuments über besagte Ansicht mit dem Bestand abgeglichen. Dieser Vorgang dauert extrem lange, da alle Dokumente in der Ansicht mit dem aktuellen Dokument abgeglichen werden. Dadurch ergibt sich ein neues Problem, denn wärend des Abgleichs könnte ein anderer Mitarbeiter ein weiteres Dokument mit der selben Nummer für das Jahr erzeugen.

Ich suche also nach einer Möglichkeit, die Prüfung zu beschleunigen, um den Kollegen wieder eine bessere Performance bieten zu können und gleichzeitig die Gefahr der doppelten Nummernvergabe deutlich zu reduzieren.

Hier mal der Code der Prüfroutine:

--- Code: ---Function NummerSuchen(jahr As String, nummer As String, refdoc As NotesDocument) As Variant

Dim s As New NotesSession
Dim db As NotesDatabase
Dim v As NotesView
Dim doc As NotesDocument

Set db = s.CurrentDatabase
Set v = db.GetView("(LUNummern)")

Set doc = v.GetFirstDocument

While Not doc Is Nothing

If Cint(doc.Ablagenummer_2 (0)) = Cint(nummer) Then
If Cint(jahr) = Cint(doc.Ablagenummer_1 (0)) Then
'Wenn das Dokument nicht neu ist
If Not refdoc Is Nothing Then
If Cstr(doc.UniversalID) <> Cstr(refdoc.UniversalID) Then
Msgbox "Die Nummer wurde schon vergeben.",16,"Hinweis"
NummerSuchen = True
Exit Function
End If

Else

Msgbox "Die Nummer wurde schon vergeben.",16,"Hinweis"
NummerSuchen = True
Exit Function

End If

End If
End If

Set doc = v.GetNextDocument(doc)

Wend

End Function
--- Ende Code ---

Mein bisheriger Ansatz wäre, für das aktuelle und das Vorjahr eigene Ansichten zu generieren, so dass hier nur jeweils bis zu ~2.500 Prüfungen nötig wären. Für alle älteren Jahrgänge sollte eine gemeinsame Ansicht reichen, da laut Aussage der Fachabteilung nur sehr selten ältere Vorgänge nachgetragen werden.

Oder gibt es eine Alternative, die noch deutlich flexibler und dennoch performant wäre?


Gruß
Dirk
 

klaussal:
Das ist mit der lfd. Nummer ist hier bestimmt schon 100te Male diskutiert worden.
Ergebnis: es geht nicht.

In der Applikation HELP ist ein Algorithmus für eine Nummernvergabe bestehend aus User-Name, Datum und Zeit.
Vielleicht wäre das die Lösung.

Keydins:
Der Aufbau der Numern (Jahr / lfdNr) kann nicht verändert werden, da wie beschrieben schon ca. 50.000 Akten im Keller gelagert sind und niemand hingehen wird, um diese 50.000 Ordner neu zu beschriften.

Mir und auch der Fachabteilung ist durchaus bewußt, dass es hier keine 100% Lösung gibt, um die Vergabe von doppelten Nummen zu verhindern. Da im Schnitt ca. 10 Einträge pro Arbeitstag erfolgen, würde eine performatere Prüfroutine jedoch die Wahrscheinlichkeit der doppelten Vergabe deutlich reduzieren.

Für den Fall, dass tatsächlich eine Nummer doppelt vergeben wurde, gibt es eine Korrekturmöglichkeit und die Kollegen der Fachabteilung prüfen zur Sicherheit nach der Anlage neuer Dokumente auch die jeweilige Ansicht auf doppelte Vergabe.

Es geht mir nur darum, die Prüfung zeitlich zu optimieren und nicht darum, ein wasserdichtes Vergabeverfahren zu implementieren.

Mitch:
Huhu Dirk,

warum läufst du denn jedes Dokument zur Prüfung einzeln durch? Mach doch lieber eine Ansicht in der die relevanten Werte in der/den ersten Spalte(n) sind und zieh dir potentielle Dublikate via view.getAllDocumentsByKey.

Zur eindeutigen Nummer: Wenn man bei neuen Dokumenten nicht unbedingt sofort eine Nummer beim Anlegen haben muss, dann kann man auch erstmal eine temporäre Nummer nutzen (z.B. die UniversalID oder über @Unique) und die richtige Nummer von einem geschedulten Agenten vergeben lassen. Wenn man dann die letzte Nummer nicht aus einer Ansicht "errechnet", sondern sie in einen (Profil-)Dokument hinterlegt, dann sind doppelte Vergaben ohnehin Geschichte.

Gruß,

Mitch

Keydins:
Hallo Mitch,

wie geschrieben, die Anwendung ist nicht von mir. Der Code ist 10 Jahre alt und ich soll 'auf die Schnelle' eine Lösung für das Performanceproblem finden. Mehr als ein paar Stunden Entwicklungsarbeit darf ich also nicht 'verbraten', somit entfallen größere Umbaumaßnahmen.

Die Idee mit dem getAllDocumentsByKey klingt auf jeden Fall nach einer Alternative, die mal testen sollte.

Navigation

[0] Themen-Index

[#] Nächste Seite