Gibt es einen guten Grund, Großbuchstaben für SQL-Schlüsselwörter zu verwenden? [geschlossen]

Die Standardeinstellung scheint Großbuchstaben zu sein, aber gibt es wirklich einen Grund, Großbuchstaben für Schlüsselwörter zu verwenden? Ich habe angefangen, Großbuchstaben zu verwenden, weil ich nur versucht habe, mit dem übereinzustimmen, was SQL Server mir bietet, wenn ich versucht habe, etwas wie eine neue gespeicherte Prozedur zu erstellen. Aber dann fühlte ich mich schrecklich für meinen Babyfinger (5.), der immer den ShiftKnopf gedrückt halten muss, also hörte ich auf, Großbuchstaben zu verwenden. Gibt es einen Grund, warum ich wieder in Großbuchstaben schreiben sollte?

Edit : Danke für die Antworten Jungs. Ich habe damals, als COBOL König war, noch nicht programmiert , also war mir das nicht bewusst. Ich werde von nun an bei Kleinbuchstaben bleiben.

Es ist nur eine Frage des Stils, wahrscheinlich aus der Zeit, als die Redakteure keine Code-Färbung durchgeführt haben.

Früher habe ich alle Großbuchstaben bevorzugt, aber jetzt neige ich mich zu allen Kleinbuchstaben.

Persönlich mag ich es nicht, wenn mein SQL mich anschreit. ES ERINNERT MICH AN GRUNDLAGEN ODER COBOL.

Daher bevorzuge ich meine T-SQL-Kleinbuchstaben mit Datenbankobjektnamen MixedCase.

Es ist viel einfacher zu lesen und Literale und Kommentare fallen auf.

SQL ist alt. OBERFALL SCHRIEBT. Es sieht seltsam aus und vielleicht hässlich.

Obwohl dies wohl zutrifft, spricht keiner dieser Gründe die besonderen Gründe für die SQL-Sprache an, warum Schlüsselwörter in Großbuchstaben eine gute Konvention sind.

Im Gegensatz zu vielen neueren Sprachen verfügt SQL über eine große Anzahl von Schlüsselwörtern und beruht auf der Fähigkeit des Lesers, Schlüsselwörter von Bezeichnern zu unterscheiden um die Syntax mental zu analysieren.

Die direkte Antwort auf Ihre Frage ist also eher eine Antwort auf die Frage, warum der Leser von SQL-Code so stark von Schlüsselwörtern in Großbuchstaben profitiert , wenn dies für die meisten modernen Sprachen nicht so zutrifft.

• Sich darauf zu verlassen, die Schlüsselwörter im Kopf zu behalten, ist für viele moderne Sprachen vernünftig, für SQL jedoch unvernünftig . Es hat zu viele Schlüsselwörter und zu viele Varianten.

• Sich auf Interpunktionshinweise zu verlassen, ist für die meisten modernen Sprachen sinnvoll, für SQL jedoch nicht zumutbar . Es gibt zu wenig, stattdessen abhängig von der genauen Reihenfolge der Schlüsselwörter, um die Syntax anzugeben.

• In modernen Fällen ist es für moderne Sprachen sinnvoll, sich bei der Unterscheidung von Schlüsselwörtern auf automatische Textmarker zu verlassen , ignoriert jedoch die Realität dessen, was Textmarker für SQL leisten können . Die meisten decken nicht alle Schlüsselwörter aller SQL-Varianten ab, und unabhängig davon wird SQL häufig und routinemäßig in Kontexten gelesen, in denen ein Textmarker nicht hilft.

Dies sind einige der SQL-spezifischen Gründe dafür, dass der Leser von SQL-Code am besten durch Standardisierung der Großbuchstaben für Schlüsselwörter und nur die Verwendung von Nicht-Großbuchstaben (dh Kleinbuchstaben oder gemischten Großbuchstaben) für Bezeichner bedient werden kann.

Hervorheben kann manchmal helfen. Aber nur, wenn der Textmarker weiß, dass Sie SQL haben. und wir haben sehr oft SQL in einem Kontext, in dem der Editor / Formatierer nicht vernünftigerweise wissen kann, dass es sich um SQL handelt. Beispiele hierfür sind Inline-Abfragen, Programmiererdokumentation und Textzeichenfolgen im Code einer anderen Sprache. Das Gleiche gilt nicht annähernd so oft für Sprachen wie Python oder C ++. Ja, ihr Code wird manchmal an diesen Stellen angezeigt, aber er wird nicht routinemäßig so ausgeführt wie bei SQL-Code.

Außerdem verwendet der Leser normalerweise einen Textmarker, der nur eine Teilmenge der Schlüsselwörter kennt, die Ihre spezifische SQL-Implementierung verwendet. Viele der selteneren Schlüsselwörter werden nur von einem hervorgehoben, der Ihre SQL-Variante genau kennt. Selbst wenn der Leser einen Textmarker verwendet, benötigt er dennoch eine direktere Methode zur Unterscheidung von Schlüsselwörtern in einer mäßig komplexen SQL-Anweisung.

Daher benötigt der Leser häufig - und der Verfasser kann nicht im Voraus wissen, wann dies der Fall sein wird - Unterstützung vom Inhalt der SQL-Anweisung selbst, um zu wissen, was der Verfasser als Schlüsselwort und was als Bezeichner beabsichtigt ist. So den SQL Inhalt selbst muss Schlüsselwörter für den Leser unterscheiden , und Groß Keywords ist die herkömmliche und nützliche Art und Weise zu tun.

Gordon Bells Beispiele sind nicht genau richtig; Im Allgemeinen werden nur die Schlüsselwörter hervorgehoben, nicht die gesamte Abfrage. Sein zweites Beispiel würde aussehen wie:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Ich finde das viel einfacher zu lesen, da die Schlüsselwörter mehr hervorstechen. Selbst mit Syntaxhervorhebung finde ich das nicht kapitalisierte Beispiel viel schwieriger zu lesen.

In meiner Firma gehen wir mit unserer SQL-Formatierung etwas weiter.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Es gab eine Zeit, in der die meisten Menschen nicht die Möglichkeit hatten, etwas jenseits von Großbuchstaben zu verschlüsseln, weil die relevante Kodierung (ASCII) noch nicht erfunden wurde. Es waren nur sechs Bits verfügbar . WÄHREND SQL NEUER IST, WAREN NIEDRIGERE FALLBUCHSTABEN BEI DER PROGRAMMIERUNG NOCH KEINE GEMEINSAME PRAXIS.

FEST , DASS Einige Leute behaupten , dass die Datenbank ein Gefühl der Dringlichkeit bekommen und Ihre Fragen schneller laufen.

Weniger als 10% der Buchstaben im Text, den wir lesen, sind Großbuchstaben. Daher ist unser Gehirn mehr daran interessiert, Kleinbuchstaben als Großbuchstaben zu erkennen. Studien haben gezeigt, dass das Lesen von Großbuchstaben länger dauert. Hier ist nur ein Beispiel:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

Das obige Beispiel unterstreicht meiner Meinung nach, dass es einen Unterschied macht, selbst wenn Sie nur über ein oder zwei Wörter sprechen.

Das liegt daran, dass SQL eine so alte Sprache ist ( 1974 ), dass die meisten Tastaturen bei ihrer Konzeption keine Kleinbuchstaben hatten! Die Sprachdokumentation spiegelte einfach die Technologie der Zeit wider.

Untersuchungen haben gezeigt, dass ALL CAPS schwerer zu lesen ist, so dass die US-amerikanische Bundesautobahnverwaltung in ihrem Handbuch für einheitliche Verkehrskontrollgeräte die Verwendung von Schildern mit gemischten Groß- und Kleinschreibung vorgeschrieben hat.

Die Beschriftung für Namen von Orten, Straßen und Autobahnen auf herkömmlichen Verkehrsschildern muss eine Kombination aus Kleinbuchstaben und Anfangsbuchstaben sein.

Die New York Post veröffentlichte auch:

Studien haben gezeigt, dass es schwieriger ist, Großbuchstaben zu lesen, und es hat sich gezeigt, dass diese zusätzlichen Millisekunden, die Sie damit verbringen, von der Straße wegzustarren, die Wahrscheinlichkeit von Unfällen erhöhen, insbesondere bei älteren Fahrern.

Es gibt keinen guten Grund, Großbuchstaben zu verwenden, und gute Gründe, dies nicht zu tun.

Ich persönlich hasse es, Großbuchstaben für SQL-Schlüsselwörter zu verwenden. Ich finde es heutzutage schwieriger zu lesen und absurd.

In der SQL-Sprache wird die Groß- und Kleinschreibung nicht berücksichtigt. Nehmen Sie Ihren Finger von dieser Umschalttaste!

Großbuchstaben können die Sichtbarkeit von Schlüsselwörtern verbessern, Sie können dies jedoch durch Hervorheben und Einrücken von Code kompensieren.
Wir verwenden Kleinbuchstaben, weil der Abfrageeditor und andere Tools beim Bearbeiten von T-SQL-Code Wunder bewirken und wir keine Notwendigkeit sehen, den kleinen Finger zu quälen.

Affe sehen, Affe tun für mich. Mustervergleich - Wenn ich es so mache, wie ich es gesehen habe, passt sich die Struktur der Klauseln mental leichter an.

Großbuchstaben sind weniger lesbar. Der Umriss aller Wörter ist wie Kästchen geformt; Es gibt keine Absteiger oder Aufsteiger. Kleinbuchstaben FTW!

Ich finde es besser lesbar. Gleiches gilt für einen Zeilenumbruch am Anfang jeder Klausel und das Einrücken zwischen Klauseln.

Versuchen Sie es mit einem Formatierungsprodukt (ich verwende SQL Prompt / SQL Refactor von Red Gate). Sie können festlegen, wie die Großschreibung funktionieren soll, und Ihr Code wird immer konsistent formatiert. Ruhen Sie Ihren kleinen Finger aus und lassen Sie den Computer die Arbeit für Sie erledigen.

Einer der Gründe für die weitere Verwendung der Großschreibung besteht darin, dass Sie (oder eine andere Person) Code in einem Notizblock anzeigen, der das Lesen erleichtert. dh Sie können leicht zwischen den "Schlüsselwörtern" und den Tabellennamen, SPs, udfs usw. unterscheiden

Anders als Konformität um der Konformität willen, nein. Obwohl es ein sehr subjektives Thema ist, bevorzuge ich die Verwendung von Groß- und Kleinschreibung für alle SQL-Anweisungen. SQL ist viel einfacher zu lesen und in modernen IDEs, in denen die Schlüsselwörter ohnehin alle farbcodiert sind, geht nichts verloren.

Die Intellisense / Autocompletion in Microsoft SQL Server Management Studio ermöglicht entweder Groß- oder Kleinschreibung für reservierte Wörter, aber Funktionsaufrufe in Großbuchstaben wie MAX (), SUM ().

Trotzdem ermöglicht der Parser weiterhin die Verarbeitung von Kleinbuchstabenversionen von max () und sum ().

Dies impliziert eine Ambivalenz in Bezug auf die Art der Ausführung und ist daher einfach eine Frage der persönlichen Präferenz.

Ich mag nichts, was in Großbuchstaben geschrieben ist (und ich hasse es, alle Großbuchstaben noch mehr zu tippen), konnte mich aber nicht davon überzeugen, gegen die Community vorzugehen. Wie immer sind Vim und die dazugehörigen Pakete die Lösung für so viele Probleme:

http://www.vim.org/scripts/script.php?script_id=305

Geben Sie einfach wie gewohnt ein und die Schlüsselwörter werden während der Eingabe automatisch großgeschrieben. Ich habe nicht alle obskuren SQL-Beschwörungsformeln verwendet, aber es hat mich noch nicht enttäuscht.

Ich rufe den größten Teil meines mySQL-Codes in PHP auf und bearbeite alle meine PHPs in vim (oder in diesem Fall vermutlich VIM ;-). Jetzt bin ich sicher, dass es Plugins gibt, mit denen der mySQL-Code in PHP hervorgehoben werden kann, aber ich habe ihn nicht gefunden und muss nicht nach ihm suchen. Deshalb ziehe ich es vor, alles in Allcaps zu haben . Ich finde das:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Hilft mir viel besser zwischen PHP und SQL zu unterscheiden:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Aus irgendeinem Grund hasse ich es auch, Allcaps mit Kamelkoffern zu mischen, wie zum Beispiel:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

Das IDärgert mich. Sollte es stattdessen sein id? oder iD?