Für Ja/Nein-Zustände wurden in Oracle-Anwendungen lange CHAR(1)-Spalten mit Y/N oder Zahlen-Flags mit 1/0 verwendet. Oracle AI Database 26ai unterstützt nun den ISO-SQL-konformen Datentyp BOOLEAN direkt in Tabellen und SQL-Ausdrücken. Das macht das Modell lesbarer und reduziert die Übersetzungslogik zwischen Datenbank und Anwendung.
NOT NULL ist – UNKNOWN als NULL.1. Neue Spalten klar modellieren
Eine Tabelle kann die Spalte direkt als BOOLEAN oder als Synonym BOOL definieren:
CREATE TABLE feature_flags (
feature_id NUMBER GENERATED BY DEFAULT AS IDENTITY,
feature_name VARCHAR2(100) NOT NULL,
enabled BOOLEAN NOT NULL
);Bei einem verpflichtenden Zustand ist NOT NULL wichtig. Damit gibt es nur TRUE oder FALSE und keine dritte Bedeutung. Wenn „unbekannt“ oder „noch nicht bewertet“ fachlich relevant ist, sollte NULL bewusst dokumentiert und in Abfragen behandelt werden.
2. SQL-Ausdrücke und NULL-Semantik
Werte können mit den SQL-Literalen TRUE, FALSE und NULL eingefügt werden:
INSERT INTO feature_flags (feature_name, enabled)
VALUES ('new_checkout', TRUE);
SELECT feature_name
FROM feature_flags
WHERE enabled = TRUE;Eine Bedingung auf FALSE erfasst nicht automatisch die unbekannten Werte. Bei einer optionalen Spalte muss die Anwendung deshalb entscheiden, ob NULL wie „nicht aktiv“, „nicht bekannt“ oder als Fehler behandelt wird. Für Vollständigkeitstests sind Abfragen auf IS NULL und IS NOT NULL ausdrücklich einzuplanen.
3. Bestehende Flags migrieren
Eine Migration von CHAR(1) oder NUMBER(1) sollte nicht mit einem unkritischen Cast beginnen. Zuerst werden alle vorhandenen Werte und Ausnahmen inventarisiert: Gibt es Kleinbuchstaben, Leerwerte, historische Sondercodes oder unerwartete Zahlen? Danach wird eine neue BOOLEAN-Spalte zunächst parallel befüllt und gegen die alte Repräsentation geprüft.
Ein typischer Ablauf ist: neue Spalte anlegen, Werte über ein explizites CASE abbilden, Abweichungen protokollieren, Anwendung und Reports umstellen und erst danach die alte Spalte entfernen. Bei großen Tabellen gehören Lock-Dauer, Online-Änderung, Rollback und Abhängigkeiten in das Migrations-Runbook.
4. Client-Treiber und Schnittstellen
Die Anwendung muss den neuen SQL-Typ ebenfalls verstehen. Oracle JDBC unterstützt den SQL-BOOLEAN-Typ in 26ai; bei Java können setBoolean und setObject verwendet werden. Für ODBC steht eine native Zuordnung bereit. Trotzdem müssen ORM-Mappings, REST-Schemas, APEX-Items, Exporte und ältere Integrationen im Zielrelease getestet werden.
Für öffentliche APIs sollte das Team außerdem festlegen, ob JSON weiterhin true/false verwendet und wie NULL übertragen wird. Eine saubere Datenbankmodellierung hilft nur, wenn die Transport- und UI-Schichten dieselbe Semantik beibehalten.
5. Praktische Checkliste
- Für jede Flag-Spalte fachlich zwischen FALSE und UNKNOWN unterscheiden.
- Neue BOOLEAN-Spalten bei zwingendem Zustand mit
NOT NULLanlegen. - Bestehende Y/N- oder 1/0-Werte vor der Migration vollständig prüfen.
- Parallelspalte, Backfill, Abweichungsreport und Rücknahmeweg planen.
- JDBC, ODBC, APEX, ORDS, ORM und Reporting im Zielrelease testen.
- Abfragen auf TRUE, FALSE und NULL in Testdaten und Fachlogik abdecken.
Fazit
Der native SQL-BOOLEAN in Oracle AI Database 26ai beseitigt viel Übersetzungslogik rund um Ja/Nein-Flags und macht SQL-Ausdrücke klarer. Der wichtigste Migrationspunkt ist die bewusste Entscheidung über NULL. Mit einem geprüften Parallelbetrieb und getesteten Client-Treibern lässt sich die neue Semantik kontrolliert in bestehende Anwendungen bringen.
Weiterführend: Oracles SQL-Referenz zum BOOLEAN-Datentyp, die Neuerungen in Oracle AI Database 26ai und die JDBC-Dokumentation zu SQL-Datentypen.