Groß-Klein-Schreibung ist in SQL weitgehend Geschmackssache. Daher hat lange gedauert bis mich mein Kollege Diethard umpolen konnte. Erst seit wenigen Jahren schreibe ich alle SQL-Schlüsselwörter groß. <\/p>\n
Ob wohl es im Zeitalter der Syntaxhervorhebung tatsächlich fast egal ist, kann man auf Ausdrucken oder in per Mail verschickten Schnipseln die SQL-Befehle tatsächlich besser lesen. Die Umgewöhnung fiel mir sehr schwer, aber der Nutzen ist tatsächlich da.<\/p>\n
Zur besseren Unterscheidung schreibe ich daher generell SQL-Schlüsselwörter groß und Variablen usw. klein. Hier ein Beispiel aus der Northwind-Datenbank:<\/p>\n
Den Name von Datenbank-Objekten sollte man hingegen generell immer "richtig" schreiben, d.h. so wie sie angelegt wurden. Deswegen habe ich im obigen Beispiel auch die Northwind-Schreibweise übernommen. Besonders wichtig wird das bei Zugriffen auf Tabellen in den Systemdatenbanken. Hier wird bei der Installation des SQL-Servers festgelegt, welche Collation verwendet wird. Hier muss ich die Objektnamen in der Regel klein schreiben, z.B.: Wegen der Übersichtlichkeit sorge ich dafür, dass Tabellen\/Views\/Procedures\/etc in unseren Anwendungsdatenbanken gleich mit einem klein geschriebenen Namen oder mit Binnenkapitälchen angelegt werden. Jedenfalls dort wo ich darauf Einfluss habe. Aber natürlich ist das auch Geschmackssache… \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":" Groß-Klein-Schreibung ist in SQL weitgehend Geschmackssache. Daher hat lange gedauert bis mich mein Kollege Diethard umpolen konnte. Erst seit wenigen Jahren schreibe ich alle SQL-Schlüsselwörter groß. Ob wohl es im Zeitalter der Syntaxhervorhebung tatsächlich fast egal ist, kann man auf Ausdrucken oder in per Mail verschickten Schnipseln die SQL-Befehle tatsächlich besser lesen. Die Umgewöhnung fiel […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[495,155],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2771"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=2771"}],"version-history":[{"count":6,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2771\/revisions"}],"predecessor-version":[{"id":2777,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2771\/revisions\/2777"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=2771"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=2771"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=2771"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}SELECT EmployeeID, LastName, FirstName, Country
\n\tFROM Employees AS Emp
\n\tWHERE Emp.Country LIKE 'U_'<\/code><\/p>\n
\nZwar sind heutzutage case-insensitive Sortierungen üblich, aber das ist eine reine Konvention. Sollte in einem zukünftigen Release mal die Datenbank mit einer case-sensitiven Collation angelegt werden, dann wird die Suche des Optimierers in den internen Systemtabellen bei "falsch" geschriebenen Tabellennamen nicht fündig. <\/p>\n
\nEXEC sp_who<\/code>
\noder
\nSELECT name FROM sys.objects<\/code><\/p>\n