Domino 9 und frühere Versionen > ND8: Entwicklung

Wie zähle ich am besten Dokumente einer View?

<< < (4/5) > >>

koehlerbv:
Wenn Dein Code nicht die korrekte Anzahl liefert (die Du sicherlich an Hand der View überprüfst), dann liegt der Fehler natürlich bei Dir.

Zu NotesDatabase.Search: Ein Performance-Test lohnt sich wirklich. Da NotesDatabase.Search keine "dumpfe Suche" durchführt, sondern interne Tables auswertet, ist es in der Regel viel flotter, als man zunächst erwarten würde.
Wenn Du aber ein paar hunderttausend Dokumente in der DB herumlungern hast, aber nur eine geringeren dreistelligen Bereich an Dokumenten im fraglichen Zeitraum darunter, dann kann das Search auch nach hinten losgehen.
In diesem Falle solltest Du dann aber die View (NotesViewEntryCollection) auswerten (und nicht jedem einzelnen Dokument erst die Hand schütteln!) - Deine Ansicht ist ja laut Schirmschuss eh schon nach Datum absteigend sortiert, so dass Du beim ersten Treffer ausserhalb des Datumsbereichs sagen kannst: "Okay, das war's - lass uns was anderes spielen!".

Bernhard

eknori:
Wenn du die Ansicht intelligent aufbaust, kommst du evtl. hiermit http://www.eknori.de/2008-12-29/get-view-column-sums-with-lotusscript/ zum Ziel. Es muss ja nicht die Ansicht sein, die der User sieht.

Peter Klett:

--- Zitat von: eknori am 12.01.11 - 06:53:22 ---... Es muss ja nicht die Ansicht sein, die der User sieht.

--- Ende Zitat ---
Ich würde Funktionen niemals von sichtbaren Ansichten abhängig machen. Wenn von den Usern ein berechtigter Änderungswunsch zu einer sichtbaren Ansicht kommt, wird die Ansicht geändert und die Funktion ist kaputt, oder Du musst den Wunsch ablehnen. Beides ist nicht gut.

Wir haben das bei uns so organisiert:

Sichtbare Ansichten haben grundsätzlich keinen Alias (Ausnahme webDefaultView oder andere Notesvorgaben)
Versteckte Ansichten haben immer einen Alias
Wird eine versteckte Ansicht von einer Routine außerhalb der Datenbank verwendet, beginnt der Name mit einem $ (natürlich nach der Klammer, sonst ist die Ansicht nicht mehr verborgen, also z.B. "($NameDerAnsicht)")
Programmatischer Zugriff auf Ansichten erfolgt immer über den Alias, niemals über den Ansichtsnamen

So kann es eigentlich nicht passieren, dass jemand eine Routine baut, die von einer sichtbaren Ansicht abhängig ist (da wäre dann ein doppelter Verstoß notwendig, 1. Zugriff auf sichtbare Ansicht, 2. Zugriff nicht über den Alias)
Änderungen von versteckten Ansichten ohne $ müssen nur in der Datenbank selbst getestet werden
Änderungen von versteckten Ansichten mit $ lässt man am besten sein
Eine Ansicht, die bisher nur intern verwendet wurde, kann problemlos in eine extern genutzte umbenannt werden, da das $ nur vor den Namen, aber nicht vor den Alias gestellt wird

Um die Datenbanken nicht mit zu vielen Ansichten unnötig zu belasten, werden versteckte Ansichten nur gebaut, wenn sie wirklich einen Vorteil bringen, und in der Regel möglichst allgemeingültig gehalten, um sie für mehrere Funktionen nutzen zu können.

Die letzten 10 Jahre sind wir gut damit gefahren.

schroederk:
Vielen Dank für den Tipp Peter, das ist sicher eine gute Regel.
In meinem Fall kann ich momentan noch wild bauen, da es innerhalb der Firma keinen Notes-Entwickler gibt (ich schließe mich dabei noch ein).
Die Datenbank ist sher simpel und ich möchte in jetzigen Fall einfach ermitteln, wieviele ein- und ausgehende Faxe wir erhalten haben. Heute und im aktuellen Monat. Da wird die vorhandene Ansicht sicherlich nicht mehr geändert und sollte es mal eine neue Version der Fax-Software geben, muss sicherlich sowieso hand angelegt werden.

Der Link über die get-view-columns-sums sieht sehr interessant aus. Vielen Dank eknori, das muss ich mir unbedingt genauer anschauen.

Im Moment versuche ich noch Troubleshooting, was mein momentanes Script betrifft. Zu einem Performance-Vergleich habe ich mal folgende Scripte zeitlich verglichen:

--- Code: --- Set doc = view.GetFirstDocument
While Not(doc Is Nothing)
str_datum = Left(doc.GetItemValue( "StartTime" )(0),10)
If str_datum = str_aktdatum Then
ges_heute = ges_heute + 1
End If
If Mid(str_datum,4,2) = Mid(str_aktdatum,4,2) Then
ges_monat = ges_monat + 1
End If
Set doc = view.GetNextDocument(doc)
Wend

--- Ende Code ---
und

--- Code: ---Set col = db.Search ({Form = "FaxForm" & StartTime = @Today}, Nothing, 0)
ges_heute = col.Count

--- Ende Code ---

Zudem das bestehende PHP-Script über die COM-Schnittstelle:

--- Code: ---
$entry = $view->GetFirstDocument();
while (is_object($entry)) {
$field = $entry->GetFirstItem( "StartTime" );
$starttime = $field->text;
if (substr($starttime,2,4) == ".$monat.") {
$efaxmon ++;
$field = $entry->GetFirstItem( "PAGES" );
$seiten = $field->text;
$eseitenmon += $seiten;
if (substr($starttime,0,3) == "$tag.") {
$efaxtag ++;
$eseitentag += $seiten;
}
}
$entry = $view->getNextDocument($entry);
}

--- Ende Code ---

Merkwürdigerweise stimmt nur das PHP-Script mit dem Wert aus der DB überein.
Die beiden Lotusscripte Code-Fragmente liefern beide einen deutlich geringeren Wert (z.b. 60 anstatt 110)

In jedem Fall lässt sich schonmal sagen, dass die Variante db.Search mindestens Faktor 10 schneller ist.

koehlerbv:
Du hast Da aber noch merkwürdigen Code: Im Fall 1 erwartest Du als StartTime einenString, im zweiten einen Datums-/Zeitwert. Das wären schon mal Äpfel und Birnen.
Weiters: Wie ist StartTime überhaupt abgelegt? Als reiner Datums- / oder als Datums-/Zeitwert oder gar gemischt? Denn 12.01.2011 16:31 ist nicht gleich Today (12.01.2011)!

Ist der Code korrekt, dann stimmt auch mit LS das Ergebnis exakt.

Zum ersten LS-Code: Du gehst hier ganz dumpf per Schleife durch alle Dokumente in der Ansicht - das ist natürlich sehr langsam (in Bezug auf NotesDatabase.Search sind das also wieder Äpfel und Birnen, die Du da vergleichst). Siehe hierzu mein letztes Posting!

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete