- Texte mit variabler Länge ( die eventuell auch mal eine zu klein vorgegebene Länge sprengen könnten ).
ntext (oder nvarchar(max)). Damit schaffen alles DMBS bis 1-2GB
- Z.B.: Namen: VARCHAR(80) - Flummi, Brummi, Zummi //<= Wie groß ist der OnDisk-Speicher versch.
DB ?
Wir haben 2022. Das interessiert keinen mehr, solange du jetzt nicht Billionen Datensätze hast.
(Aber i.d.R. speichern
DBMS das optimiert ab.
- Z.B.: Namen: VARCHAR(80) - TextMitMehrAls80Zeichen => Könnte auch mal 90 Zeichen kommen, dann kracht es.
Ja
- Wieviel realer Speicher wird in den verschiedenen
DB wirklich belegt ?
Wo? Festplatte (Datenmenge + Menge der Indeze die du benötigst
- Speichern von
UniCode (UTF8) Texten muss möglich sein.
Gähn. Kann jede
DB.
Unicode-Problem ist eigentlich sowas von 90iger Jahre.
- Möglichst per Volltextsuche durchsuchbar, sollte einigermaßen effizient sein.
Gibts viele Möglichkeiten. Je Effizienter, desto mehr
DB-Eigenheiten von
SQL-Syntax bei Abfrage und Anlegen
- Möglichst indizierbar (geht das überhaupt bei TextBlobs, oder muss ich selbst von außen Hashes verwalten ) ?
textblobs können auch Indiziert werden. Da koste (AFAIK) jedes
DBMS sein "eigens Süppchen". Also kein
SQL-Standard
- Wie kann ich große TEXT Blobs effizient per
SQL durchsuchen und in Queries einbinden ?
Abhängig
DBMS, wenn effizient sein soll
- Macht es Sinn große TEXT Blobs in separate Tabellen, mit HASH Columns, auszulagern, oder machen die modernen
DB sowas automatisch ?
Je nachdem. Alles ist möglich und viele
DBMS können das konfiguierbar machen.
Wenn du aber viel mit (großen) Textdaten machst, dann schau dir mal Lucene oder den großen Bruder ElasticSearch an.
GB/TB große Textmengen können sehr schnell durchsucht werden.