Wenn man die Datenbank bzw. später die Tabelle immer mit CHARSET NONE erstellt, hat man in einer geschlossenen Welt (z.B. nur Deutsch) keine Probleme mit Umlauten.
Sobald aber Mehrsprachigkeit gewünscht wird (z.B. West-/Osteuropa) wäre eine Einstellung mit UTF8 empfehlenswert.
https://de.wikipedia.org/wiki/Zeichensatztabelle
Selbst nur für Westeuropa/USA hast du schon verschiedene Codepages:
850 DOS-Latin-1
437 USA
1252 Windows ANSI
Hier hast du schon unsere Umlaute auf verschiedenen Codepunkten.
Um die Daten für alle aber einheitlich darstellen zu können, bietet sich für die DB z.B. 1252 an, da dies zu 850/437 kompatibel ist.
Bei der Connection-Einstellung gibt man dann an, mit welcher Codepage man arbeitet, der Treiber macht dann automatisch die Umsetzung.
Somit kann ich z.B. die DB ebenso in UTF8 erstellen (Platz ist ja heute kaum ein Problem). Die Felder werden dann in 4facher Größe erstellt: 1 Zeichen = 4 Bytes, da UTF8 ein variabler Zeichensatz zwischen 1 bis 4 Bytes verwendet.
Auf Grund der Satzkomprimierung in der Firebird steigt der benötigte Platz noch nicht mal an.
Arbeitet der Client z.B. mit WideChar (Strings z.B. sind immer Unicode 2-Byte, UCS2), erfolgt die Umwandlung auch automatisch durch den Treiber.
Hat man seine Datenbank aber auf z.B. NONE (Binär) oder 1252 fixiert wird es nicht einfach, Mehrsprachigkeit einzuführen.
Man muss dann für jede Tabellenerstellung explizit CHARSET UTF8 angeben.
Hier eignen sich i.Ü. auch sehr gut Domains (CREATE DOMAIN) für die Verwaltung von Feldtypen.
https://firebirdsql.org/file/documentat ... mn-de.html