Tabellen und Constraints - Grundkurs Datenbanksysteme - page 104

Einige SQL-Dialekte erlauben es übrigens auch, die explizite Längenbegrenzung
bei varchar auszulassen. Hier kann man aber - je nach RDBMS - böse Überra-
schungen erleben. Es gibt die folgenden Möglichkeiten:
varchar entspricht einem Text beliebiger Länge (H2).
varchar entspricht varchar(1) (IBM Informix).
Der zweite wichtige Datentyp für Textspalten ist char . Wenn wir ihn zur Definiti-
on unserer Personentabelle nutzen
create table personen(
id int primary key,
name char(20)
)
werden für jeden Datensatz 24 Byte reserviert. Der Plattenplatz wird somit mög-
licherweise nicht optimal genutzt. Das hat zur Folge, dass wir mehr Platz und so-
mit mehr Transporte zwischen der Platte und dem Hauptspeicher benötigen. Die
Vorteile des Typen varchar werden also zu den Nachteilen von char und um-
gekehrt. Wenn wir es mit Texten fester Länge, wie Kürzeln oder Postleitzahlen, zu
tun haben, ist char eine vertretbare Wahl, im Zweifelsfall sollten wir aber den Ty-
pen varchar vorziehen. Tabellen, die intensiv mit char -Spalten arbeiten, findet
man heute oft in Altsystemen: Der Typ varchar hat sich erst Ende der 1990er-
Jahre durchgesetzt.
Neben diesen beiden Typen für Texte kann es - je nach RDBMS - zahlreiche weite-
re geben. So wird bei der Verwendung von char und varchar ein Byte pro Zei-
chen verwendet. Dieser sehr stark begrenzte Zeichensatz reicht für Zeichensätze
wie die chinesischen Kanji-Zeichen nicht aus. Oft werden daher auch Datentypen
mit 16 Bit pro Zeichen angeboten.
Zahlen: In Programmiersprachen wie Java wird zwischen Typen für ganze Zahlen
und solchen für Gleitkommazahlen unterschieden. Neben diesen beiden Klassen,
gibt es in SQL noch die Festkommazahlen. Bei den ganzen Zahlen haben wir -
auch wieder analog zu Java:
small : Für die Darstellung der Zahlen werden zwei Byte verwendet.
integer : Der Typ kann auch mit int abgekürzt werden und benötigt 4 Byte.
bigint : Beim Datentyp int ist bei Zahlen im Bereich von ein paar Milliarden
Schluss. Wenn wir aber in eine Tabelle mit einem künstlichen vom RDBMS
verwalteten Primärschlüssel sehr viele Datensätze einfügen und löschen, kann
es passieren, dass diese Obergrenze erreicht wird. Lücken in den Werten des
Primärschlüssels werden nicht vom RDBMS geschlossen. Wenn wir es also
mit sehr großen Tabellen mit volatilen Inhalten zu tun haben, kann der 8 Byte
Datentyp bigint für den Primärschlüssel die bessere Wahl sein. Ein kurze
Überschlagsrechnung (siehe auch [Kar10]) zeigt indes, dass die Obergrenze