Datenbank mit zu vielen Doks - Was ist möglich (ODBC..)?

[lotus blue]

Hallo liebe Forumsgemeinde,

bräuchte mal wieder euren Rat bzw. Empfehlung.

Wir haben eine Artikel Bestands DB im Einsatz die derzeit über 600.000 Doks umfasst.

Die Dokumente sind nicht gerade groß, da ja "nur" Artikelname, vier Datumsfelder und ein Feld für die History in der Maske vorhanden sind.
Es ist davon auszugehen, dass die DB bis Ende 2011 über 1 Mio Doks umfaßt.

Grds. kam mal die Idee zunächst per ODBC auf ne Oracle DB zuzugreifen, aber dadurch vermindert sich ja nicht die Anzahl der Doks in der DB ja auch nicht.
Hat jemand schon mal ähnlich gelagerte DB´s verändert, angepaßt?
Welche Möglichkeiten hätte ich noch? Quasi Notes nur als Anzeige zu Nutzen, mit den ganzen ACL Möglichkeiten usw.?

Viele Grüße

[atbits]

1 Mio - Dokumente sind grundsätzlich mal kein Problem.

Kritisch ist Folgendes:
 - Wieviele Ansichten enthält die DB? Irgendwann kommt der Updall nicht mehr in annehmbarer Zeit durch
 - Entferne die ungelesenen Markierungen, wenn ihr diese nicht benötigt (was bei solchen DB's in der Regel nicht der Fall ist)
 - Wäre evtl. Archivierung nicht aktiver Artikel in eine Archiv-DB eine Möglichkeit, von dieser kann man die Artikel bei Bedarf wieder reaktivieren
 - Woruaf Du anspiels (Notes nur als Frontent), wäre z.B. mit LEI und virtual Documents möglich, das kann ich aber aus persönlicher Erfahrung nicht empfehlen - gerade bei einer großen Dok-Anzahl geht das gerne in die Hose
 - Oder aber direkt DB2 als Datastore verwenden, aber ob das eine zukunftsichere Technologie ist bezweifle ich (das ist aber auch meine persönliche Einschätzung)

Grüße David

[lotus blue]

1 Mio - Dokumente sind grundsätzlich mal kein Problem.

Kritisch ist Folgendes:
 - Wieviele Ansichten enthält die DB? Irgendwann kommt der Updall nicht mehr in annehmbarer Zeit durch
 - Entferne die ungelesenen Markierungen, wenn ihr diese nicht benötigt (was bei solchen DB's in der Regel nicht der Fall ist)
 - Wäre evtl. Archivierung nicht aktiver Artikel in eine Archiv-DB eine Möglichkeit, von dieser kann man die Artikel bei Bedarf wieder reaktivieren
 - Woruaf Du anspiels (Notes nur als Frontent), wäre z.B. mit LEI und virtual Documents möglich, das kann ich aber aus persönlicher Erfahrung nicht empfehlen - gerade bei einer großen Dok-Anzahl geht das gerne in die Hose
 - Oder aber direkt DB2 als Datastore verwenden, aber ob das eine zukunftsichere Technologie ist bezweifle ich (das ist aber auch meine persönliche Einschätzung)

Grüße David

Hallo,
vielen Dank für Deine Antwort.
Also Ansichten dürfte nicht das Problem sein, es sind momentan 12 Stück.
Die Ungelesenen Markierungen sind aber ein guter Tipp. Danke
Archivierung ist leider nicht möglich.

MIt den anderen Varianten hab ich bisher auch nix am Hut.

Danke nochmals

[atbits]

Und haben diese 12 Ansichten vielleicht sortierbare Spaltenheader, oder sind sie kategorisiert und enthalten sowas wie @DocDescendants in der Kategorie.

12 Ansichten können ganz schön heftig sein, wenn sie nicht richtig ausgelegt sind.
Oder enthalten die View-Selection-Formulas vielleicht @Today oder Ähnliches.

Ich würde mir mal im Administrator die größen der View-Indices anschauen.
Wenn ein View-Index über die Maßen groß ist, dann mal darüber nachdenken, ob man diese eine View vielleicht optimieren kann.

Grüße David

[Peter Klett]

Ich hatte dieses Jahr ein ähnliches Problem lösen müssen. Eine Datenbank, die für 1 Mio Dokumente angefordert und bis 2,5 Mio Dokumente getestet war, flog mir bei 4,5 Mio Dokumenten um die Ohren (eine Ansicht, 1 Maske, 20 Felder, alle bis auf eines mit IsSummary = False, kein direkter manueller Zugriff auf die Datenbank).

Die Lösung bei uns sieht folgendermaßen aus:

- Definition mehrerer Datenbanken als Speicherort (wir nutzen derzeit 10)
- Routinen
 - Erstellen neuer Dokumente: immer in die leerste Datenbank, Schlüssel wird vorab abgefragt
 - Suchen von Dokumenten: in allen Datenbanken, erster Treffer gewinnt (doppelte gibt es aber nicht)

Überrascht war ich darüber, dass sich das Laufzeitverhalten fast nicht verändert hat, insbesondere die Suche über die 10 Datenbanken ist nicht spürbar langsamer, als die in einer Datenbank.

Natürlich wäre auch möglich, eine Logik zu schaffen, die die Zuordnung in die einzelnen Datenbanken ermittelt, das war in unserem Fall aber nicht möglich, da alle Datensätze sehr ähnlich sind. Die Performance zeigt auch, dass es nicht notwendig gewesen ist. Die Datenbanken sind nun alle mit etwa gleich vielen Dokumenten ausgestattet. Wird die Anzahl der Dokumente je DB kritisch, wird die Anzahl der Datenbanken erhöht.

[lotus blue]

Ok Danke Euch. Hat mir schon mal weitergeholfen. Werd wohl die Ansichten-TUnning machen