Freitag, 2. September 2011

Technische Unterschiede PostgreSQL, MySQL, MariaDB - Teil 5

Die vorangegangenen Teile dieser Artikelserie sind hier:
  1. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql.html  
  2. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql_30.html  
  3. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql_31.html  
  4. http://miraspostgresqlwelt.blogspot.com/2011/09/technische-unterschiede-postgresql.html
Andere arbeiten lassen
Man könnte PostgreSQL unterstellen es sei faul. Man könnte PostgreSQL aber
genausogut unterstellen, es sei verdammt clever.

Einer meiner Professoren sagte einst, Erfinder und Entwickler sind von Natur aus faul, denn Erfindern und Entwickler, entwickeln Dinge, die das Leben einfacher machen sollen. Die Hauptinitiative hierfür ist meist Faulheit.

Egal - in jedem Fall lässt PostgreSQL eine wesentliche Aufgabe von anderen machen, um die sich MySQL selbst kümmert:

Wie werden Texte sortiert? Wie passen Symbole in Form von Buchstaben zueinander? Welches Symbole sind die passenden Kleinbuchstaben zu den Symbolen der Großbuchstaben? Für die Antwort dieser Fragen gibt es einen fachspezifischen Oberbegriff: Collations.

Wirft man Symbole, die irgendwie logisch zusammen passen, auf einen Haufen, so spricht man von Charsets. Ein Haufen an Symbolen kann zum Beispiel das lateinische Alphabet, das arabische Alphabet oder römische Zahlen sein.

Werden den jeweiligen Symbolen in dem Haufen bestimmte Bits und Bytes zugeordnet, spricht der Fachmann von Encoding. Die Begriffe Charset
und Encoding werden gerne durcheinandergeworfen. Zumal häufig Charsets und dazugehörige Encoding auch noch den gleichen Namen haben. In der Regel wird aus dem Zusammenhang schnell deutlich, was gemeint ist.

Encodings und Charsets begegnen uns in der Computerwelt immer und immer wieder. Die meisten Anwender bekommen davon jedoch wenig mit. Es funktioniert einfach. Doch das es funktioniert, ist manchmal ein kleines Wunder. Wer hier bei Datenbanken nicht aufpasst, kann sich schnell seine Datensätze irreparable zerschießen. Sowohl bei PostgreSQL als auch bei MySQL. Das gilt für alle mir bekannten Datenbanksysteme.

Ich wollte hier aber auf Collations hinaus:

Collations regeln zum einen die Sortierung. Also zum Beispiel ist dort geregelt, dass einem 'a' ein 'b' folgt. Aber auch, dass ein Großes 'A' gemeinsam mit dem kleinen 'a' sortiert wird oder erst alle Großbuchstaben, dann alle kleinen.

Daneben ist in einer Collation festgehalten, welche großen Buchstaben zu welchen kleinen passen. Also das 'A' und 'a' zusammengehören. Oder, wenn die Sprache es so vorgibt, vielleicht auch 'Y' und 'i'. Wie sieht ein 'ß' in Großbuchstaben dargestellt? Auch diese Frage wird hier beantwortet.

Als drittes ist hier festgelegt - was noch wie zusammengehört. Hier brauch ich nicht in die Ferne schweifen. Die Collation regelt ob ein 'ä' als 'ae' oder als 'a' ausgelegt wird.

MySQL hat diverse Collations, Charsets (Encodings) selber implementiert. PostgreSQL bedient sich hier einfach der Implementation der libc.

Als Experte für Lokalisierung und Globalisierung könnte ich ein ganzes Buch über dieses Thema schreiben. Vorallem, über die Beschwerden, die zu meinen MySQL-Zeiten bei mir auf dem Tisch landeten.

Allein für deutsch gibt es mindestens vier unterschiedliche Sortierregelungen. Die Schweizer und die Österreicher sortieren anders als die Deutschen, und in Deutschland gibt es dann auch noch gleich zwei verschiedene Regeln (wir nennen sie gern Dudensortierung und Telefonbuchsortierung).

Reichlich deutsche Anwender beschwerten sich über die deutsche Sortierung von
MySQL. Das war noch einfach für mich, weil ich konnte ihnen einfach die DIN
(5007) unter die Nase halten und zeigen, MySQL macht es richtig.

Bei einigen anderen Sprachen war es wesentlich schlimmer. Eine Sortiernorm konnen wir nicht ausfindig machen. Scheinbar gibt es hier keine Norm. Jeder Anwender hatte eine andere Theorie was richtig und was falsch ist. Belegen konnten die Anwender Ihre Theorien nicht.

Daneben gibt es Unicode und einen Unicode Standard der sich ebenfalls mit Sortierung, Groß-/Kleinschreibung und Buchstabenersetzung befasst.

Eines ist hier sicher - allen recht machen, kann man es einfach nicht.

Glaubt mir, das selbst implementieren bringt mehr Ärger als Nutzen. Auch bei PostgreSQL bekomme ich diese Art von Beschwerden, doch wenn ich hier sage, dafür ist libc verantwortlich, nehmen die meisten es einfach hin.

Der Anwender kann bei MySQL sogar seine eigenen Collation bauen. Wer gerne ein X nach dem D statt nach dem W sortieren möchte, kann dafür eine eigene Collation bauen.

Meine Erfahrung hier ist jedoch, dass 99,8 % der Anwender, die sich jemals mit dem Gedanken befasst haben, eine eigene Collation zu bauen, sich am Ende, aufgrund der Komplexität die das Bauen eine Collation mit sich bringt (vor allem im Unicode Bereich), doch mit dem zufrieden gegeben haben, was vorhanden
ist.

PostgreSQL bedient sich hier der libc. Bei PostgreSQL wird das Encoding / Collation einmalig, bei der Initialisierung der Intanz festgelegt und es gilt danach für den gesamten Cluster (Instanz) und kann nachträglich nicht geändert werden. Bei MySQL kann ich es nach belieben ändern, allerdings müssen Indexe, die hier auf Spalten liegen, bei denen der Charset geändert wurde, natürlich neu erstellt werden.

Mit PostgreSQL 9.1 lassen sich collations auch Spaltenweise festlegen.

Gemischte Collations in einer Instanz habe ich allerdings auch bei MySQL bislang eher selten gesehen. Die meisten Datenbanken nutzten durchgehend eine Collation. Mir fallen durchaus Anwendungsfälle ein, bei denen unterschiedliche Collations pro Instanz vorkommen könnten, doch genau bei diesen Anwendungen stellt sich mir dann auch gleich die Frage "will man das wirklich in einer relationalen Datenbank machen oder doch lieber NoSQL?".

Fortsetzung folgt ....


Keine Kommentare:

Kommentar veröffentlichen