Dokumente in anderer Datenbank anzeigen

[TomLudwig]

Guten Morgen zusammen,

ich möchte gerne alle Dokumente die in Datenbank A liegen, in einer Ansicht in Datenbank B anzeigen. Ist dies überhaupt möglich?

Ich möchte keine Ansicht in Datenbank A halten. In Datenbank A sollen nur Dokumente (keine Gestaltungselmente) liegen.

Viele Grüße und Danke!

[m3]

Nein.

[TomLudwig]

War mir irgendwie klar...

Trotzdem danke

[ata]

... so wie du das willst - ohne eine Ansicht in DB "A" geht das nicht - du benötigst mindestens eine Ansicht - und die wäre dann mit einer Gliederung und Framework in jeder beliebigen Datenbank anzeigbar...

Toni

[TomLudwig]

Genau das wollt ich ja umgehen ;-)

Ich möchte wirklich kein einziges Gestaltungselement in der Datenbank A haben ...

... vielleicht fällt mir was ein, wie ich die Ansicht in DB B nachbauen kann...
... ala Dokumente per Script aus DB A selektieren und per Hyperlinks anzeigen...

... ich werde berichten...

DANK EUCH VIELMALS

[m3]

Und mit welcher Form werden die Dokumente dann angezeigt, wenn Du keine in der DB hast? Abgesehen davon, dass die Navigation mühsam wird, wenn Du nicht mal eine View in der DB hast.

[ata]

... um die Datenbank im Frontend öffnen zu können benötigt man mindestens eine Ansicht. Dein Vorhaben kann nicht klappen...

Was spricht denn gegen die Ansicht?

Toni

[Thomas Schulte]

Und selbst mit Hyperlinks brauchst du mindestens eine Ansicht in deiner Basisdatenbank damit der Link funktioniert.

[hwenck]

Ich habe eine DB in der sich Inhalte bestimmter Docs jede Minute ändern können. In der DB wird keine eigene Ansicht benötigt. Die Änderungen werden im Backend abgefragt und via AJAX im Web dargestellt. Der Vorteil ist die nicht benötigte Indizierung. Sehr speziell aber möglich.

[koehlerbv]

Die Indizierung musst Du dann aber letztlich an anderer Stelle nachholen 

Bernhard

[hwenck]

Schlagt mich nicht ! db.search

[koehlerbv]

Warum sollten wir Dich schlagen (wollen)?
Nur: Was hilft Dir dbSearch, um eine ANSICHT an anderer Stelle zu simulieren?

Bernhard

[hwenck]

Die Indizierung ist zu langsam und bremst den Server aus (alle User). Für db.search ist kein Index notwendig . Dies ist bestimmt keine allgemeine sonden eine spezielle Lösung. Die Darstellung wird auf den Client ausgelagert. (mühsam)

[Axel]

Die Indizierung ist zu langsam und bremst den Server aus (alle User).

 

Das verstehe ich nun gar nicht.

Axel

[TomLudwig]

Wow, was habe ich da angefangen ;-)

Aber das wäre auch ungefähr mein Ansatz gewesen. Die Dokumente die in Datenbank "B" liegen per db.Search aus Datenbank "A" selektieren. Irgendwie Hyperlinks erstellen und per UNID wieder öffnen.

Dann muss ich die DB "B" nie im Frontend öffnen und brauche somit keine einzige Ansicht.

Gegen die Ansicht spricht eigentlich nichts. Die Frage hab ich mir rein aus interesse gestellt und wollte eure Meinung dazu hören. Ich wollte die Datenbank "B" "sauber" halten. Es sollten keine Gestaltungselemente in der DB liegen. Auch keine Ansicht, sodass die DB eben nie geöffnet werden kann ... Schlagt mich wenns unsinnig war ... Ich finds intressant...

[m3]

Die Indizierung ist zu langsam und bremst den Server aus (alle User).

 

Das verstehe ich nun gar nicht.

Axel

Er schrieb:

Ich habe eine DB in der sich Inhalte bestimmter Docs jede Minute ändern können.

Ich vermute mal, dass der Ansichts-Updater bzw. der FT-Indexer für ihn nicht oft genug/schnell genug läuft.

[hwenck]

Der Sonderfall:
In der DB befinden sich ca 4000-10000 Dokumente. Jede Minute können sich 0 bis ca. 300
Dokumente in einem Wert ändern. Alle 15 Minuten ändern sich ca 20 bis 30 Felder in
jedem Dokument. In einer "normalen" DB ca 15 bis 20 Ansichten (auch kategorisierte) führt
das zu langen Indizierungen. Der "Unsinn" besteht darin, die Zeit auf den Client zu verlagern.
Mit Antwortzeiten von 1-5s kann ein einzelner Nutzer bei einer speziellen Abfrage leben.
Die Ausgabe wird dann im Browser zusammengestellt. Die Aktualisierung des Index wirkt sich aber auch auf Ansichten aus.
Also: alle "dynamischen" Felder werden in einer separaten DB abgelegt und nur im Backend abgefragt. Das Laufzeitverhalten auf dem Server hat sich damit wesentlich verbessert.
Bei einer langen Laufzeit ca 14 Tage ohne Eingriff vergrößert sich die DB von ca 100MB auf über 700MB. In dem Sonderfall bleibt die Datenbankgröße konstant.