Dankesehr für die Antworten.
Im Wesentlichen denke ich geht es mir um zwei Anwendungsfälle:
- Variabler Texte, relativ überschaubarer Länge, welche aber mal das Limit reißen könnten
( z.B. Daten im Durchschnitt 40-80, gewählt VARCHAR(120), es könnten aber mal Daten 150 auftauchen.
- Variabler Text, relativ großer Länge, der möglichst durchsuchbar bleiben sollte.
( z.B. Daten im Durchschnitt 1-2K, gewählt VARCHAR(4096), ist das effizient ?).
Bezüglich der VARCHAR Storage-Erfordernisse:
- Nahezu alle RDBMS speichern den Text + Längeninformation (2 Byte)
- Speicherung ist meistens effizienter bei Feldern die länger als 4 Zeichen sind
- Umgekehrt ist die Performance schlechter, da zusätzliche Umwandlungen stattfinden. Die Länge ist nicht durch DDL sondern Daten definiert
Also wäre die Empfehlung bei VARCHAR zu bleiben, weil die
DB's mit Sicherheit entsprechend der realen Daten,
und nicht der Kapazität anwachsen werden.
Bezüglich
SQL Abstraktion
Da gibt es viele Fallstricke, aber generell kann man mit FireDAC vieles abstrahieren.
Gibt es denn irgendwo schöne Tutorials dazu, die sich dem Abstrahieren annehmen ?
Im Orginal FD ist ja schon Vieles dabei, aber so richtig bin ich noch nicht drauf gekomen wie es am besten angewendet werden möchte.
Es gibt halt jede Menge Wahlmöglichkeiten, aber da habe ich die Qual.
- 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
Siehe oben, 1.), 2.), also von den Extremen bin ich wohl weit genug entfernt.
Genau deswegen bin ich nicht so sicher ob man sich einfach auf die
DB's verlassen sollte, oder versuchen sollte etwas zu optimieren.
Die Anwendung wird sicher nicht kritisch werden, aber das habe ich schon oft gedacht und es ist dann doch passiert
- 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.
Genau das wollte ich ja wissen ( sorry, bin auch erst kürzlich aus dem 20ten Jahrhundert hier in 2022 angekommen
)
Mein letztes größeres
DB-Projekt ist ein paar Jahre her, und ich habe nicht verfolgt was sich seitdem (10-15J) so getan hat.
Mal provokant gefragt, wenn die
DB das alles wegoptimieren, warum dann nicht einfach immer VARCHAR( 4K ) oder so setzen,
auch wenn ich real nur ca. 80 Zeichen brauche und ich habe Ruhe und trotzdem ein genauso effizientes, speicherschonendes System ?
- Wieviel realer Speicher wird in den verschiedenen
DB wirklich belegt ?
Wo? Festplatte (Datenmenge + Menge der Indeze die du benötigst
Ja Festplatte, Speicher, ich bin sicher es gibt gutmütige
SQL Konfigurationen und welche die eine
DB sprengen könnten.
Ich hoffe da für 1.) und 2.) stark auf das wegoptimieren, weil ich mich ja wohl nicht in Extrembereichen aufhalte.
Billiarden Datensätze habe ich auch nicht zu Erwarten.
- Speichern von
UniCode (UTF8) Texten muss möglich sein.
Gähn. Kann jede
DB.
Unicode-Problem ist eigentlich sowas von 90iger Jahre.
Sorry, wollte es nur erwähnen, weil ich hier in der
DP immer noch zig
UniCode Threads sehe.
So ganz scheint das ja noch nicht verinnerlicht zu sein, ich erwarte da aber auch keinerlei Probleme seitens moderner
DB und mit D11.
- 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
Schade, aber war ja zu Erwarten.
Was würde man denn als "große" textblobs ansehen, fiele Fall 2.) schon darunter, oder bleibt das bei VARCHAR( 4K ) ?
Denn darum geht es mir.
"Echte" TextBlobs, mit 100K oder so, da würde ich ein Durchsuchen auch nicht mehr Erwarten.
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.
Ja ElasticSearch ist auch mein heimlicher Favorit, allerdings muss ich wohl ohne auskommen.
Es wird auch kein MongoDB o.ä. möglich sein, wel ich auf einem virtuellen Server (ohne Docker) bleiben möchte.
Hochskalieren oder in die Cloud kann man damit ja später immer noch.
Ich habe aber gesehen dass es auch sowas wie MongoSqlite gibt, in dem eine Sqlite
DB Mongo "simuliert".
Das ist sehr wahrscheinlich nicht besonders effizient, aber interessant ist es trotzdem.
Warum sollte eine hochoptimierte
DB nicht auch sowas unterstützen ?