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

128

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.

Hertanto Lie
quelle
9
Versuchen Sie es mit der Feststelltaste. :)
MusiGenesis
7
Ich muss immer noch CAPS LOCK aktivieren, wenn ich Schlüsselwörter schreiben möchte, und dann deaktivieren, wenn ich keine Schlüsselwörter schreibe, und CAPS LOCK wieder aktivieren und so weiter und so fort. Es ist nur ein Ärger.
Hertanto Lie
17
CAPS wha ... Oh, du meinst meine dritte Strg-Taste?
Dave Sherohman
2
IIRC, das Lustige ist, dass wenn Sie die sp_-Prozeduren in MSSQL überprüfen, sie alle in Kleinbuchstaben geschrieben sind.
Benjol
1
@Benjol, nicht alle, aber definitiv viele von ihnen mögen sp_who. Es ist eine gute Idee, zumindest zu versuchen, im selben Bereich konsistent zu sein, was Microsoft in vielen "Fällen" nicht tut. Wortspiel, beabsichtigt. LOL
Gordon Bell

Antworten:

107

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.

Mitch Wheat
quelle
6
+1 Ich glaube, ich war nicht der einzige, der alle Senken für Keywords verwendet hat.
Dance2die
2
Ich gehe davon aus, dass es bis in die Zeit zurückreicht, als die Redakteure keine Code-Färbung durchgeführt haben.
Benjol
10
Ich bin mir ziemlich sicher, dass es auf die Zeit zurückgeht, als viele Maschinen keine Kleinbuchstaben unterstützten.
Nate CK
1
Ich würde vermuten, dass es bis in die Tage vor Farbmonitoren
zurückreicht
149

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.

Gordon Bell
quelle
8
Es ist so sehr Geschmackssache. Nach meiner Erfahrung ist die Menge an Schreien nicht zu groß - ich bevorzuge die Großbuchstaben, da sie viel einfacher zu lesen sind und Literale und Kommentare hervorstechen.
Jonathan Leffler
93
+1 für "Ich mag es nicht, wenn mein SQL mich anschreit"
dance2die
8
Ich mag es nicht, wenn eine Sprache mich anschreit, aber das bringt nicht die Frage auf, ob Großbuchstaben in SQL eine gute Idee sind.
Bignose
85

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.

große Nase
quelle
Ich denke, der enge Grund für diese Frage ist ziemlich gut. Ihre Antwort ist gut erklärt, sieht aber immer noch ein bisschen meinungsbasiert aus. Ich habe nicht das Gefühl, dass SQL so viele Schlüsselwörter hat. Wie oft sehen Sie nach den 50 häufigeren Keywords andere? Ist es immer noch wichtig, sie in Großbuchstaben anzuzeigen? Da sie selten sind, neigen sie sowieso dazu, Aufmerksamkeit zu erregen, nicht wahr? Natürlich throwverdienen diese verdammt kniffligen "nicht reservierten Schlüsselwörter" als SQL-Server eine besondere Behandlung, aber Großbuchstaben sind nur eine Option zwischen vielen.
Frédéric
1
@ Frédéric, Sie scheinen zu argumentieren, dass der Leser keine weniger bekannten Schlüsselwörter benötigt, um als Schlüsselwörter markiert zu werden. Nein, solche Wörter fallen nicht gerade deshalb auf, weil vom Leser nicht erwartet werden kann, dass er weiß, dass es sich um Schlüsselwörter handelt. Deshalb müssen sie wie alle anderen als Schlüsselwörter unterschieden werden.
Bignose
Vielleicht kenne ich SQL trotz meiner langjährigen Programmierung mit SQL einfach zu wenig, aber bis jetzt glaube ich, dass ich immer fast sofort Schlüsselwörter entdeckt habe, die ich nicht kannte, weil sie zu einem ungewöhnlichen SQL-Konstrukt führten, zumindest für jemanden, der dies nicht tut kenne sie.
Frédéric
33

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
davidtbernal
quelle
1
Ja, so mag ich es auch.
David der Mann
6
Das Problem ist ... Wenn Sie beim Ausführen von Ad-hoc-Befehlen an einer Eingabeaufforderung Kapital schlagen, sind Sie immer halb so schnell wie jemand, der sie nicht großschreibt, wenn Sie jemals Ad-hoc-Befehle in der Produktion ausführen müssen, wenn dies der Fall ist Angelegenheiten. Also schreibe ich alles in Kleinbuchstaben und "verschönere es" vor dem Einchecken, wenn sich jemand beschwert, dass er es nicht lesen kann, weil er nicht weiß, wie man einen Syntax-Textmarker ausführt. Und ich weiß nichts über Sie, aber die drei Male im Jahr, in denen ich Ad-hoc-Befehle in Produktionsgeschwindigkeit ausführen muss, sind wirklich wichtig, sodass sich die 50% der Arbeitstage, an denen ich das Schreiben von Testanfragen in Kleinbuchstaben geübt habe, wirklich auszahlen.
7
Und in der Datenbank meines Unternehmens (die irgendwo in den 90er Jahren erstellt wurde) werden alle Tabellennamen, Spalten, Indizes, gespeicherten Prozeduren usw. großgeschrieben, daher werden SQL-Schlüsselwörter in Kleinbuchstaben verwendet. ;)
Andreas
1
Wow 1/2 so schnell. Das glaube ich nicht!
Iharob Al Asimi
33

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.

Lukas Eder
quelle
Also heute kein guter Grund.
Bignose
1
@ BIGNOSE: NEIN, ABSOLUT NICHT!
Lukas Eder
1
Ich denke, das ist die beste Antwort. Leider hasse ich Kleinbuchstaben in SQL-Schlüsselwörtern und finde keinen Weg, Kleinbuchstaben zu mögen. Bin ich verrückt?
Iharob Al Asimi
@IharobAlAsimi JA, SIE SIND VERRÜCKT. WARUM SCHREIBEN SIE ENGLISCH IN UNTEREM FALL, ABER MOT STRUKTURIERTES ENGLISCH?
Lukas Eder
24

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.

AaronLS
quelle
5
Wir sprechen nicht davon, einen Roman in Großbuchstaben zu lesen. Wir sprechen über eine Handvoll Schlüsselwörter, die nur einen Teil des Textes ausmachen.
Casey
6
Sie verpassen den Punkt. Es geht nicht darum, wie viele Wörter wir lesen, sondern darum, wofür unser Gehirn schnell trainiert wurde. Ein Straßenschild zum Beispiel ist sicherlich kein Roman, aber sie sind zu dem gleichen Schluss gekommen. Wenn wir lesen lernen, beginnen wir mit dem Lesen jedes Buchstabens, aber schließlich beginnt unser Gehirn, ein Wort als eine Gruppe von Mustern zu erkennen. Es ist besser, wenn diese Muster konsistent sind. Denken Sie daran, dass Großbuchstaben oft ein anderes Muster als Kleinbuchstaben haben und nicht nur eine größere Version.
AaronLS
1
Es gibt jedoch nur sehr wenige Schlüsselwörter, die immer wieder vorkommen. Die Erkennung sollte daher für jeden gleich schnell sein, der SQL für einen beliebigen Zeitraum verwendet.
Casey
3
Es ist definitiv nichts Hartes und Schnelles. Es gibt jedoch nur wenige Schlüsselwörter, die sehr häufig vorkommen. Es gibt eine große Menge, die es nicht gibt, und oft erweitern die Leute diese Praxis des oberen Gehäuses auf Dinge, die eingebaute Funktionen sind, aber nicht unbedingt syntaktische Sprachschlüsselwörter. In der Praxis habe ich noch eine kleine Handvoll Schlüsselwörter wie SELECT / WHERE / GROUP BY, die den Beginn eines Hauptabschnitts einer Abfrage anzeigen. Aber auch alle anderen Schlüsselwörter, wie eingebauten Funktionen wie cast, rankich Fall senken.
AaronLS
19

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!

Böhmisch
quelle
3
Ich denke, die Verbreitung guter Gründe, die in anderen Antworten angegeben sind, spricht gegen Ihre Behauptung, dass es keinen guten Grund gibt, Großbuchstaben zu verwenden.
Bignose
7
@bignose Oh, es gibt Gründe ... Ich glaube einfach nicht, dass sie gut sind. Nach meiner Erfahrung ist es umso wahrscheinlicher, dass der SQL-Programmierer Großbuchstaben verwendet, je jünger er ist. Umgekehrt habe ich noch nie einen kompetenten SQL-Codierer getroffen, der Großbuchstaben verwendet.
Böhmisch
3
Absolute Zustimmung. Die Verbreitung anderer "Antworten" macht sie nicht korrekt, sondern nur prävelant. ALLE OBEREN FÄLLE SIND EIN HANGOVER, VON WEM COMPUTER KEINE FÄLLE AUF IHREN TASTATUREN ODER IN IHREN CHARAKTERVERTRETUNGEN HABEN. ES IST HEUTE NUR DUMM.
Charles Bretana
Ja, und tragen Sie Ihre CAPS LOCK-Taste oder verkrampfen Sie Ihre Finger, indem Sie die Umschalttasten unnötig gedrückt halten.
Gordon Bell
9
Ich rieche hier Zirkelschluss. Wenn der Grund für die Unterscheidung von Schlüsselwörtern mit Groß- und Kleinschreibung angegeben wird, wird dies als kein guter Grund abgetan. Wenn der Grund von einem SQL-Codierer angegeben wird, Ihre Position jedoch nicht übereinstimmt, werden Sie als nicht kompetenter SQL-Codierer abgetan. Ich denke auf dieser Grundlage können wir dies als ungültiges Argument abweisen.
Bignose
8

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.

Ovidiu Pacurar
quelle
2
Ist der Abfrageeditor und t-sql die einzigen Stellen, an denen jemand Ihren SQL-Code liest? Woher weißt du das?
Bignose
8

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.

dkretz
quelle
7

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

Lance Fisher
quelle
3
Der von Ihnen angegebene Grund unterstützt die Position, dass Großbuchstaben dazu beitragen, Schlüsselwörter von den anderen zu unterscheiden.
Bignose
5
@bignose Wenn SQL wie eine menschliche Sprache liest, warum brauchen wir dann Großbuchstaben? Wir müssen unsere Verben oder Präpositionen in menschlicher Sprache nicht in Großbuchstaben schreiben. Stellen Sie sich vor, JEDER Satz sah so aus. Ich finde das weniger lesbar als normales Schreiben. Die Großbuchstaben in diesen beiden Sätzen bewirken, dass mein Gehirn anhält und sie langsamer sagt als der Rest des Satzes, was mein Lesen verlangsamt und den Fluss weniger natürlich macht.
Chris Middleton
1
Die menschliche Sprache verzeiht sehr vieldeutig in der Syntax. Computersprachen sind es nicht, deshalb müssen diese Mehrdeutigkeiten minimiert werden. Die SQL-Syntax hilft dabei nicht weiter, daher müssen wir die verfügbaren Tools verwenden. Die SQL-Syntax hat nicht viel zu bieten, daher haben wir die Konvention der Großschreibung von Schlüsselwörtern weiterentwickelt.
Bignose
5

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

Mark Bostleman
quelle
2

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.

gfrizzle
quelle
1
Dieser Rat ignoriert die vielen Kontexte, in denen SQL gelesen wird. Es ist völlig unpraktisch, Code zu lesen, der bereits von jemand anderem geschrieben wurde. Wenn ein solches Tool benötigt wird, um schlecht formatiertes SQL lesbar zu machen, spricht dies für eine Konvention wie die in dieser Frage angesprochene.
Bignose
Dieser Ansatz ist jedoch gut, wenn Sie unternehmensweite Standards wünschen. Wenn Sie Standards wollen, spielt die Meinung keine Rolle
Trubs
2

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

CPU_BUSY
quelle
1

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.

Charles Bretana
quelle
Da viele andere Antworten hier Gründe dargelegt haben, glaube ich nicht, dass Ihre Antwort richtig ist: Es gibt Gründe, die „aus Gründen der Konformität nicht konform sind“.
Bignose
... was sind sie dann? Obwohl ich immer offen für neue Informationen bin, habe ich ehrlich gesagt nie etwas davon bemerkt.
Charles Bretana
Ich habe bereits viele Gründe angegeben , jetzt wissen Sie es.
Bignose
2
Keiner dieser Gründe ist gültig, sondern eine persönliche Präferenz. Fühlen Sie sich frei, dies zu tun, wie es Ihre persönlichen Vorlieben vorschreiben, aber charakterisieren Sie eine Präferenz in der Regel oder als Best Practice nicht.
Charles Bretana
1

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.

Rechnung
quelle
4
Ja, und in SSMS "Optionen -> Texteditor -> Transact-SQL -> Intellisense" können Sie die Standardeinstellung auf "Kleinbuchstaben" setzen, wenn Sie dies bevorzugen.
Gordon Bell
0

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.

Ferdinand van Wyk
quelle
-2

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?

puk
quelle
3
Nein, nein, nein, camelCase ist für Variablennamen, nicht für Spaltennamen. Verwenden Sie die richtige Groß- und Kleinschreibung für Spaltennamen ... InsertDate, AlterDate, ...
Gordon Bell
1
Der SQL-Standard erfordert, dass Implementierungen Groß- und Kleinschreibung in Bezeichnern ignorieren (er faltet sie in Großbuchstaben um). Ihr Code sollte also nicht von Fallunterschieden bei Bezeichnern abhängen, und der herkömmliche Weg, dies zu tun, besteht darin, Bezeichner zu erstellen all_lower_case.
Bignose
3
@bignose Ich bin kein großer Fan des Unterstrichs, da er wpm verringert
puk