Zeichenkette in DB speichern, nicht in Profil-Dokument oder Dokument?

[JulianBuss]

Ich würde gerne eine kurze Zeichenkette, d.h. eine Note-ID, in einer Datenbank derart speichern, dass sie dieses Datum repliziert wird, aber nicht in einem Dokument oder Profil-Dokument gespeichert ist.

Hintergrund: ich habe eine eigene Mechanik für den schnellen und direkten Zugriff auf Dokumente gebaut, die ohne Ansichten auskommt. Das basiert natürlich auf einer "Tabelle", wo ein Key einer Note-Id zugeordnet ist. So kann ich anhand des Keys in der Tabelle nachgucken, bekomme die Note-ID und hole daran das entsprechende Notes-Dokument.
Im Grunde also sowas wie Profil-Dokumente, nur mit normalen Notes-Dokumenten.

Der Hintergrund davon ist, das man mit Profil-Dokumenten beliebig viel Ärger in replizierenden Umgebungen bekommen kann. Ich hatte da schon die originellsten Phänomene...

Diese "Tabelle" ist ebenfalls in einem Notes-Dokument abgelegt, sozusagen dem "Root"-Knoten.
Daraus folgt, dass ich die Note-ID dieses "Tabellen"-Dokuments irgendwo so ablegen muss, dass ich sie schnell auslesen kann.
Natürlich kann ich diese Note-ID in einem Profil-Dokument ablegen... schneller und einfacher Zugriff ohne Ansicht: ja, aber in replizierenden Umgebungen handelt man sich damit u.U. wieder Probleme ein.

Aber wo sonst soll man sowas speichern können? Gibts irgendwelche lustigen versteckten Datenspeicher in einer Notes-Datenbank?

Natürlich könnte ich auch eine Ansicht bauen und dieses "Tabellen"-Dokument darüber holen... das kostet aber wieder Performance :-)

[animate]

mal so ein Tipp ins Blaue.
in diesem Thread ist ein Link zum LDD-Forum


http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/e7c540d767f6fe7d80256e1200561fd8?OpenDocument


da steht, wie du DB-Eigenschaften nach XML exportierst, änderst und wieder zurückschreibst. Vielleicht kannst du da zu den DB-Eigenschaften eigene Attribute bzw. Elemente definieren?!?!

[koehlerbv]

Profildokumente - kann ich nachvollziehen ;-) Wenn es auch mit R5 zumindest deutlich "ruhiger" geworden ist.
Es sollte auch sicherlich möglich sein, in irgendeinem Notes-Dokument - Design-Elemente sind ja auch nicht anderes als Dokumente - weitere Informationen in eigenen Items abzulegen - hier ist Phantasie und Experimentierwillen angesagt. DatabaseIcon oder Agents wären solche Kandidaten, die man mal ausprobieren könnte.
A-Bär: Auch Design-Elemente werden (wie ProfileDocs) über Ansichten erreicht, genauso, wie das beim Zugriff über NoteID oder UniversalID passiert - es stehen immer Tabellen dahinter.
Wenn Du in einem Dokument NoteIDs ablegen willst, dann können dies ja nicht sooo viele sein, sonst stösst Du da ja an Grenzen.
Ich selbst lege zentrale Informationen (global setup usw.) in "normalen" Dokumenten ab, die meist das einzige Dokument in einer speziellen Ansicht sind. Performanceprobleme habe ich damit noch nicht bekommen, die bottle necks liegen immer woanders.

Bernhard

[JulianBuss]

ja, mir fiel gestern abend auch noch ein, dass man die ID z.B. im "About"-Dokument speichern könnte, dass man über eine fixe Note-ID sehr schnell bekommt.
Aber: bei einem Design-Refresh wird das ja überschrieben... geht also auch nicht.

Ich denke ich probiere das mit der Ansicht auch, ist halt nur wieder ein Design-Element mehr :-)

[Glombi]

Eine Überlegung am Rande:
NoteID und Replikation ist aber auch nicht so ohne, da die NoteID nicht eindeutig ist. Besser wäre die die UNID.

Du könntest die gewünschte NoteID in einem Dokument mit einer "fixen" NoteID speichern, dann kannst Du mit Deiner Methodik auf dieses Dokument zugreifen und die NoteID lesen.

Andreas

[Axel]

Hi,

die Probleme mit Profildokumenten kenne ich. Ob es bei Version 6 immernoch so ist kann ich im Moment nicht sagen. Für die Version 5 hab ich mir mal eine Alternativ-Lösung erstellt.

Schau mal hier:
http://www.free.dominoserver.de/computer/noteslibrary.nsf/d2d59a3d7fc73a2bc1256a6900638352/74e4b61d04ca824dc1256db20041582a!OpenDocument

Vielleicht hilft dir dass ein bisschen weiter, wenn du es etwas anpasst.

Ich würde nicht auf die About- Dokumente der DB gehen, sondern ein ganz normales Dokument verwenden. Notfalls kannst du es ja von der Aktualisierung beim Gestaltungsupdate ausnehmen.

Axel

[Diddl]

du könntest natürlich jedes beliebige design dokument verwenden. design dokumente sind normale dokumente die nicht über normale ansichten gefunden werden und eben die design element beinhalten.

natürlich müßtest du das betreffende designdoc vom überschreiben durch 'gestaltung wechseln' schützen.

[JulianBuss]

ja, die Idee habe ich aber verworfen. Eben weil ein Design-Dokument nicht mit absoluter Sicherheit vor einem Refresh/Replace geschützt werden kann.

Ich habe jetzt zähneknirschend erstmal die Variante mit der Ansicht genommen: es gibt eine Ansicht dir nur genau dieses eine Dokument anzeigt (wenn vorhanden). Das hole ich mir dann via view.getfirstDocument().

Das ist ziemlich schnell, trotzdem finde ich es nicht ideal weil ich 1.) ein weiteres Gestaltungselemente kopieren muss und 2.) ein weiteres Ansichts-Objekt instanziiert wird.
Für sich genommen sind das natürlich Kleinigkeiten, aber zusammen mit der Komplexität unserer Anwendungen ist es halt wieder ein Stückchen Aufwand mehr :-)

Ich habe aber wirklich keine andere Lösung gefunden. Wenn es Server-basierte Umgebungsvariablen geben würde - das wäre cool....

[Glombi]

Deine Lösung mit einer Ansicht und einem extra Dokument ist hinsichtlich Wartbarkeit und Robustheit eine gute Wahl. Der Weg mittels Verwendung eines Designelements zwecks Speicherung von Informationen halte ich eher für gewagt und störanfällig, insb. im Hinblick auf Designupdates bzw. neuere Notes-Schablonen.

Andreas

[JulianBuss]

...und man erinnere sich: der ganze Stress wäre nicht nötig, wenn die Profil-Dokumente vernünftig und vor allem zuverlässig funktionieren würden :-(((

Aber however, jetzt haben wir wenigsten eine Lösugn, die auch im Web und auch für Schreibzugriffe zuverlässig und für alle Benutzer funktioniert :-)