ids-system GmbH Tipp #3 Leer-Strings in SQL oder die Frage nach CHAR oder VARCHAR

Transkript

1 ids-system GmbH Tipp #3 Leer-Strings in SQL oder die Frage Zusammenfassung Dieses Dokument beschreibt die Unterschiede zwischen CHAR und VARCHAR Datentyp sowie die Behandlung im SQL Michael Tiefenbacher

2 Problem Was ist der Unterschied in Bezug auf Leerstrings und Leerzeichen bei den DB2 Datentypen CHAR und VARCHAR? Macht denn VARCHAR(1) überhaupt Sinn? Der Vergleich mit NULL-Werten wird an dieser Stelle nicht besprochen es befindet sich aber ein Verweis auf einen Blog-Eintrag zu diesem Thema unter Weitere Referenzen am Ende des Dokuments. Grundlagen Während bei CHAR die volle Länge von vornherein allokiert wird, wird bei variablen Feldern also z. B. VARCHAR nur die vorhandenen Zeichen gespeichert und zusätzlich eine Längeninformation. VARCHAR-Felder brauchen also nur den Platz der auch mit Zeichen befüllt ist plus die Längeninformation, während bei CHAR-Feldern die restlichen Zeichen mit Leerzeichen aufgefüllt werden (Hex 0x20). Der Update von VARCHAR-Feldern kann so zu einer Vergrößerung des Datensatzes führen und ggf. dazu, dass die Zeile nicht mehr auf die Page passt und als OVERFLOW-Row in einer anderen Speicherseite abgelegt werden muss. Rein speichertechnisch benötigt ein VARCHAR(1) Feld also mehr Platz auf der Platte als ein CHAR(1) Feld, da eben die zusätzliche Längenangabe mit gespeichert wird. Beispiel: create table chartest (id int, c1 char(1), v1 varchar(1), c2 char(10), v2 varchar(10)); insert into chartest values (1, 'A', 'A', 'AAAAA', 'AAAAA' ), (2, ' ', ' ', ' ', ' ' ), (3, '', '', '', '' ), (4, ' ', '', ' ', ' ' ), (5, '', ' ', ' ', ' '); select id, c1, length(c1) as length_c1, v1, length(v1) as length_v1, c2, length(c2) as length_c2, v2, length(v2) as length_v2 from chartest; Gibt folgende Werte zurück: ID C1 LENGTH_C1 V1 LENGTH_V1 C2 LENGTH_C2 V2 LENGTH_V A 1 A 1 AAAAA 10 AAAAA /

3 Na gut sowohl Leerzeichen als auch Leerstrings sind hier nicht besonders gut zu sehen also machen wir ein paar zusätzliche Abfragen select id, c1, length(c1) as length_c1, v1, length(v1) as length_v1 from chartest where c1 = v1; Überlegen wir mal hier vorab, was wir als Ergebnis erwarten. Zeile 1 und 2 sollten zurückgegeben werden, da dort auch identische Werte eingegeben wurden. Dies gilt eigentlich auf für Zeile 3, da jedoch wurde ein Leerstring eingegeben und da in CHAR Leerzeichen gespeichert werden ist hier die Antwort nicht so offensichtlich. Bei 4 und 5 wurden unterschiedliche Werte eingegeben werden diese also als Ergebnis erwartet? Schauen wir uns das Selektionsergebnis an: ID C1 LENGTH_C1 V1 LENGTH_V A 1 A Zur besseren Sichtbarkeit wurde die Tabelle künstlich mit den Eingabewerten angereichert ID C1 LENGTH_C1 V1 LENGTH_V A 1 A 1 2 ' ' 1 ' ' 1 3 '' 1 '' 0 4 ' ' 1 '' 0 5 '' 1 ' ' 1 Alle fünf Zeilen sind im Ergebnis. Interessant ist, dass die unterschiedlichen Werte als identisch angesehen werden und die Längen zeigen, dass die Inhalte unterschiedlich sind. Haben wir jetzt bewiesen, dass 1=0 ist? Die Länge des C1 Feldes ist immer 1 was durch die Charakteristik von CHAR zu erklären ist. Auch die Länge von V1 ist zu erwarten. Wieso also wird der Leerstring in der V1 Spalte mit dem Leerzeichen ( Blank ) in C1 gleichgesetzt? Hierzu ein Auszug aus der DB2 Dokumentation: When comparing character strings of unequal lengths, the comparison is made using a logical copy of the shorter string, which is padded on the right with blanks sufficient to extend its length to that of the longer string. This logical extension is done for all character strings, including those tagged as FOR BIT DATA. 03/

4 ACHTUNG: Dies bedeutet, dass bei den kürzeren Strings die Inhalte mit Leerzeichen aufgefüllt werden, bis die Strings dieselbe Länge haben. Dabei ist es unerheblich ob der kürzere String in einer Spalte steht oder als Parameter übergeben bzw. codiert wird. Somit ist ein Vergleich von Strings auf Unterschiede in Leerzeichen am Ende nicht direkt möglich und es muss in diesen Fällen wirklich mit der LENGTH() Funktion gearbeitet werden. select * from chartest where v1 = ' ' (=> Ergebnis: Row 2-5) select * from chartest where v1 = '' (=> Ergebnis: Row 2-5) Hier werden auch jeweils die kürzeren Strings auf den potentiell größeren Vergleichsstring aufgefüllt (gepadded) was dann auch erklärt, warum das 2. Statement ebenfalls alle Zeilen liefert (ohne der Zeile mit A ). Vergleich per LIKE-Prädikat Bei = -Vergleichen gelten die oben genannten Regeln was aber wenn man mit LIKE arbeitet? Ausgehend von obiger Beispieltabelle ändern wir unsere Abfragen nun auf eine LIKE-Klausel ab: select * from chartest where v1 like ' ' select * from chartest where v1 like '' Und siehe da das erste SQL liefert als Ergebnis die Zeilen mit der ID 2 und 5 und das zweite die mit der ID 3 und 4! Bei LIKE-Prädikatsabfragen wird also NICHT mit Leerzeichen aufgefüllt (gepadded)! Dies findet auch im SQL Cookbook von Graeme Birchall im Kapitel Quirks in SQL. Somit dürfte jetzt auch klar sein, was folgende SQLs zurückliefern: select * from chartest where c1 like ' ' (=> Ergebnis: Zeilen 2-5) select * from chartest where c1 like '' (=> Ergebnis: nichts) 03/

5 Verhalten in einer externen Anwendung (DataStage) Das bisher Gezeigte bezieht sich auf SQL bzw. DB2. Macht man den identischen Vergleich außerhalb z.b. mit DataStage ergibt sich ein ganz anderes Bild. Bild 1: Vergleich in DataStage Hier werden die Datensätze aus der DB2-Tabelle gelesen und eine Bedingung in der TX_Compare Transformator Stage reicht nur die Sätze weiter bei denen C = V ist. Nur die Sätze mit ID 2 und 3 werden durchgereicht und somit als gleich erkannt. Das sind die, bei denen auch die Länge übereinstimmt. Ein weiterer Test mit einer Anreicherung über Lookup unterscheidet ebenfalls die unterschiedlichen Eingaben: Bild 2: Lookup über CHAR-Spalte in DataStage 03/

6 Wird der Lookup über die Spalte C vollzogen. Beim Lookup in DataStage treffen beide generierte Zeilen vom Typ CHAR. Bild 3: Lookup über VARCHAR-Spalte in DataStage Ändert man den Lookup auf die VARCHAR-Spalte treffen Inputsatz 2 und 3 auf den Satz1 aus der Referenz und Inputsatz 1 und 4 auf den Referenzsatz 2. Also somit Blank auf Blank und Leerstring auf Leerstring. Weitere Referenzen NULLs Serge Rielau Blog ull43?lang=en SQL Cookbook (unter Quirks in SQL Use of LIKE on VARCHAR 03/