Obwohl der Clustered Index in der Mehrzahl der Fälle ein korrekt sortiertes Resultset zurückgibt, gibt es keine Garantie hierfür. Wenn man ein SELECT Statement ohne explizites ORDER BY ausführt, versucht SQL Server die Daten in der schnellstmöglichen Sortierung zurückzugeben, was nicht unbedingt, die des Clustered Index ist.
Inzwischen besitze ich eine ganze Reihe von Büchern von Joe Celko, und ich muss sagen, dass mit jedem Buch der Deja-Vu Effekt ansteigt.
Vieles von dem, was in "Thinking in sets" geboten wird, kann man in der einen oder anderen Form auch in früheren Büchern, und natürlich auch in den diversen Communities, in denen Celko präsent ist, nachlesen.
Man muß nicht einmal besonders genau hinschauen, um zu sehen, daß die meisten Applikationen mit Daten in dieser oder jener Form arbeiten. Oftmals sind diese Daten in einer Datenbank gespeichert, so daß man davon ausgehen kann, daß die meisten Software Entwickler mehr oder weniger regelmäßig mit Datenbanken arbeiten. Nun ist aber Datenbankprogrammierung etwas anders als Applikationsprogrammierung und von daher ist es nicht selbstverständlich, daß ein guter Applikationsentwickler gleichzeitig auch ein guter Datenbankentwickler ist. Dabei spielt es übrigens keine Rolle, ob als Datenbanksystem eine Desktopdatenbank wie Microsoft Access zum Einsatz kommt oder ein ausgereifter relationaler Datenbank-Server wie der Microsoft SQL Server. Paradigmen, Grundsätze und Richtlinien, die für Applikations Entwicklung gelten, gelten nicht auch zwangsläufig für die Datenbankentwicklung und können teilweise sogar eher gegenläufig sein. Dennoch gibt es auch in der Datenbankentwicklung einen deutlichen Bedarf an Regeln und Richtlinien für die Entwicklung und hier kommt das vorliegende Buch ins Spiel. Sein Autor, Joe Celko, zählt zu den prominentesten Vertretern der Datenbank Community und hat einige der besten Bücher über SQL Programmierung im Allgemeinen geschrieben. Dieses Buch jedoch ist anders. Es zeigt einem nicht, wie man ein "besserer" SQL Entwickler wird, indem es Lösungen und Tricks zu SQL Rätseln und Brainteasern präsentiert. Dieses Buch will vermitteln, wie man in logischen und deklarativen Begriffen denkt und arbeitet.
Folgendes kann man in dem Buch lesen:
Auf den über 200 Seiten präsentiert Celko seine Sicht eines Frameworks, innerhalb welchem Datenbankentwicklung erfolgen sollte. Sei dies eine Diskussion darüber, was eine gute Namenskonvention ausmacht oder wie SQL Code geschrieben und eingerückt werden sollte. Sei dies eine Diskussion darüber, ob Auto-Nummern (auch bekannt als SQL Server's IDENTITY Eigenschaft) ein guter Schlüssel sind oder wo im Code CHECK Einschränkung platziert werden sollten.
Einige der präsentierten Regeln sind (hoffentlich) gesunder Menschenverstand, für manche anderen existieren internationale Standards und weitere wiederum sind eher Celko-spezifisch. Sämtliche Regeln werden zusammen mit einer Begründung und gegebenenfalls Ausnahmesituationen für die jeweilige Regel angeführt. Dies macht aus dem Buch eher eine Art Nachschlagewerk, welches man im Zweifelsfall zu Rate zieht, als ein "normales" Buch, welches man Kapitel für Kapitel von vorne bis hinten liest. Auch wenn man in manchen Punkten nicht unbedingt mit Joe Celko übereinstimmen muß, kann man dieses Buch hervorragend als Grundlage nehmen, um darauf seine eigenen Programmierstil Richtlinien aufzubauen.
Zweifelsohne gibt es einen Bedarf an solchen Richtlinien, und so ist, zum Beispiel, die schlechteste Namenskonvention, immer noch besser als gar keine. Aber es macht das Leben eines Datenbankentwicklers (und, wahrscheinlich noch wichtiger, das Leben desjenigen, der den ursprünglichen Code pflegen muß) deutlich einfacher, wenn ein klarer und konsistenter Programmierstil angewendet wird. Viele der Regeln in diesem Buch sind nicht wirklich neu für Leute, die den Online Communities folgen, an denen Joe Celko ebenfalls partizipiert, aber dieses Buch fasst diese Regeln sehr schön an einem einzigen, greifbaren Ort zusammen und das allein bietet schon genug Anreiz zu Kauf.
SQL Programming Style Joe Celko 2005 Morgan Kaufmann 272 Seiten ISBN 0-12-088797-5 |
Es gibt keine Unterschiede zwischen ISNULL und COALESCE. Diese Meinung kann man recht häufig in Online Communities lesen. Der einzige Unterschied zwischen beiden ist, daß ISNULL SQL Server spezifisch ist, während COALESCE ANSI-SQL Standard ist. Auch dies kann man recht häufig lesen. Beide beschäftigen sich mit der Umwandlung von NULL und damit fehlenden Informationen. Wozu also einen eigenen Beitrag?