Zwischenspeichern von temporären Informationen

    Hallo,


    ich bin gerade dabei eine Startdatenbank für unsere Notes Clients, ähnlich der IBM Bookmark.nsf, zu programmieren.


    Die Datenbank soll mehrere Rahmen beeinhalten und es müssen Informationen zwischen den Rahmen ausgetauscht werden können. (Klickt ein User auf eine Schaltfläche im Linken Rahmen, soll z.b. der Inhalt im mittleren Rahmen geändert werden.) Ebenso müssen temporär für den angemeldeten Benutzer bestimmte Informationen in der DB zur Verfügung stehen (Speicherorte für andere Datenbanken, seine Personalnummer in unserem Unternehmen ...... ).


    Die Datenbank soll lokal auf den Clients zur Verfügung gestellt werden, soll aber auch auf dem Server betrieben werden können und soll für einen Update-Modus bzw. um bestimmte Dokumente
    zwischen einzelnen Clients austauschen zu können Replizierfähig sein.


    Nun meine Frage wo kann ich diese Temporären Informationen am besten zwischenspeichern ?


    Ich dachte im ersten Versuch über ein Profiledokument nach, alternativ dachte ich an die Notes.ini oder eventuell sogar über eine zusätzliche lokale Datenbank in der ich dann die Informationen in einem Dokument zwischenspeichern würde.


    Hat hierzu jemand Erfahrung, was hier die beste Variante ist, auch im Hinblick auf die Performance und eventuelle Probleme bei der Replizierung der DB.


    Für Anregungen wäre ich dankbar.

    Ein komplexes Thema, Michael.
    Ausschliessen kannst Du die NOTES.INI (jeder Admin wird Dir dankbar sein, wenn das Teil nicht zugemüllt wird, und "transportabel ist diese auch nicht).


    Denkbar: Wenn überschaubar viele User, die Portal-DB selbst mit personal profiles.
    Eine eigene DB erfordert wieder Admin-Aufwand. Scheint mir inadäquat.
    Sauber: Ein Profile im Mailfile des Users (erfordert keinen Eingriff ins Mailtemplate!).


    Ansonsten: Mehr Input, mehr Output.


    Bernhard

    Hallo Bernhard,


    ok Notes.ini scheidet aus, das habe ich mir fast gedacht.
    An UserProfile - Dokumente habe ich auch schon dran gedacht, wir haben allerdings ca. 600 User und ich bin mir nicht ganz sicher ob die Verwaltung von sovielen User - Profiles in einer
    Replizierten Umgebung sinnvoll ist.
    Ein Profile im Mailtemplate wäre eine Möglichkeit, allerdings würde das dann ja auch immer einen Zugriff auf den Server zur Folge haben, wenn z.B. in der Startdatenbank ein neues Register aufgerufen wird oder ein Reload des Framesets stattfindet. Ich möchte die Zugriffe auf den Server so weit wie möglich einschränken um den Server so weinig wie möglich zu belasten.
    Da wir für andere Anwendungen bereits eine Cache - Datenbank lokal ausbringen müssen, werde ich wohl die Informationen in dieser DB ablegen. Das scheint mir von der Performance her die beste Variante zu sein.

    Was die Serverzugriffe angeht, so liegst Du falsch, Michael: Dies erfolgt nur einmalig beim ersten Zugriff auf ein ProfileDocument, anschliessend liegt dieses bis zum Schliessen der DB im Speicher des Notes-Clients.


    Bernhard

    Ok ich dachte immer das auch ein Profildocument immer wieder neu geladen wird. Dann wäre es von der Performance her kein Problem Profiles zu verwenden. Da die Informationen ja nur temporär gespeichert werden sollen, könnte man dann ja auch ein Profile in der DB anlegen und dieses Profile beim Schliessen der DB wieder löschen.
    Aber sicherer wäre es dann noch mit User-Profiles, ist das ratsam bei einer Anzahl von ca. 600 ?

    Rein theoretisch sind auch 60.000 ProfilesDocuments kein Problem. Praktisch würde ich es aber nicht machen.
    Zu bedenken ist aber, dass Du mit hunderten ProfileDocuments zumindest etwas eine DB aufblähst. Nimmst DU dagegen das Mailfile, ist es immer nur *ein* Profiledokument ...


    Wovon ich drngend abrate, ist das Löschen der ProfileDocuments. Wozu sollte das gut sein? Du erzeugst nur sackweise Deletion Stubs, die dann wiederum Deine DB verstopfen.
    Ab gesehen davon: Die DB muss ja auch gar nicht geschlossen werden - schon ein Stromausfall kippt Deine Idee.


    HTH,
    Bernhard