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
- Bei NVARCHAR gibt es das Problem, dass die Länge nicht der Zeichenanzahl entspricht und eine Berevhnung daher immer nur eine Näherung sein kann
Bezüglich "string truncation":
- Firedac besitzt FormatOptions [fvStrsTrim, fvStrsTrim2Len] "Strings auf Maximallänge kürzen" um gewollten Datenverlust zu unterstützen. Damit vermeidet man Copy beim Setzen der Parameter
Bezüglich BLOB
Für Text BLOB und deren Handling kocht jede
DB ihr eigenes Süppchen (bzgl. Maximaler Länge, RegEx, CAST etc.). Dort würde ich ein generisches Dictionary selber aufbauen oder spezifisch mit SP arbeiten, die dann einen Cursor zurückgeben oder entsprechende Views aufbauen.
Allgemein kann man auch sagen, dass
DB, die sehr gutes und performantes BLOB Handling anbieten, sowohl teuer als auch Speicherschweine sind.
Bezüglich
SQL Abstraktion
Da gibt es viele Fallstricke, aber generell kann man mit FireDAC vieles abstrahieren. Vieles kann aber auch nicht richtig funktionieren, z.b. das Limit() Handling bei Subselects. Sehr schön sind auch die Macros (z.b. für Tabellennamen). Auch Stringzusammensetzungen sind sehr unangenehm.
Firebird
SQL:
Code:
Kunden.Land || '-' || Kunden.Plz || ' ' || Kunden.Ort as Importeur
FireDac
SQL:
Code:
{Concat({Concat({Concat({Concat(Trim(Kunden.Land),''-'')}, Trim(Kunden.Plz))}, '' '')}, trim(Kunden.Ort))} as Importeur