Zitat von
shmia:
Meine Erklärung:
ein Blob-Feld löst allein schon durch sein Vorhandensein zusätzliche Aktionen in der
DB aus.
Vorallem werden Blob-Daten physikalisch auf anderen Seiten als die Tabelle gespeichert.
Daher ergeben sich zusätzliche Festplattenzugriffe.
Betrifft den OP aber nicht, da er sich glücklicherweise nicht mit
MSSQL rumärgern muss.
Wie bereits schon von anderen beschrieben, geht Firebird den Weg des gesunden Menschenverstandes und verwendet Lob locators.
Sind sogar cooler als bei Oracle implementiert (wie mkinzler auch schon schrieb
).
Zitat:
Workaround:
Man speichert die Blobdaten nicht direkt in der Tabelle, sondern in einer eigenen Tabelle.
Dies erfordert einen zusätzlichen Primärschlüssel für die Blobtabelle und einen Fremdschlüssel (pro Blobfeld) für die Orginaltabelle. (Datentyp int32 verwenden!)
Falls man die Blob-Daten wirklich braucht, kann man gezielt nur Blobdaten für den aktuellen Datensatz abrufen.
lol, und da sieht man wieder was passiert, wenn ein
DBMS ein server-basiertes
Access sein will. *g*
Lob locators sind nix weiter als Pointer auf den wirklichen Lob, der an einer anderen Stelle in der Datenbank liegt.
Das heißt man kann in Firebird (oder fast jedem anderen
DBMS) auch in Tabellen mit Lobs wunderbar schnell suchen und sogar Daten ändern. Die Lobs kommen erst ins Spiel wenn man sie tatsächlich anfasst.
Also praktisch das was du da selbst basteln musstest.
FB geht sogar noch weiter und wird kleine Lob-werte direkt in den Record packen, wenn dieser dann immer noch in die angefangene Page passt.