2010-07-01 5 views
9

SQL scheint die am meisten vernachlässigte Sprache zu sein, wenn es darum geht, schön und lesbar zu formatieren ... Und da SQL-Anweisungen unglaublich detailliert und komplex sein können, macht es das extrem schwer mit zu arbeiten. Aber ich finde, wenn ich versuche, meinen SQL-Code bestmöglich zu formatieren, bin ich manchmal unsicher, wie ich das machen soll. Ich kenne die Standards für Java, C#, Python, etc .... aber wenn es um SQL geht, habe ich nicht zu viele Richtlinien oder akzeptierte Praktiken gesehen. Was sind Tipps/Regeln zum Formatieren von SQL, damit es klar, lesbar und logisch ist? Können Sie Beispielcode zur Veranschaulichung angeben? Was haben Sie als die gängigste und akzeptierte Form der SQL-Formatierung gefunden?So stellen Sie sicher, dass mein SQL-Code kein gruseliges Durcheinander ist

+0

Ich neige dazu, SQL mich zu vermeiden, schreiben, ein Chaos zu vermeiden ... – driis

+1

kein neues Thema.Sehen Sie sich http://stackoverflow.com/questions/118288/sql-coding-style-guide und andere mit den Tags "coding-style" und "sql" an. –

+0

Gibt es Standards für Java und C# Formatierung? Verbreite das Wort, es könnte schließlich die endlosen heiligen Kriege über Klammerstil und Tab-vs-Space-Einrückung stoppen. –

Antwort

11

Sie könnten versuchen, Joe Celkos Buch SQL Programming Style auszuprobieren. Ich bin sicher, dass es viele Leute gibt, die mit seinem Stil nicht einverstanden sind, aber es ist ein guter Anfang.

Einige meiner eigenen „Regeln“

  • SQL-Schlüsselwörter sind immer alle Großbuchstaben
  • Tabellennamen „richtige“ Fall sind, während Spalten und Variablen sind alle Klein
  • Jeder " major“Klausel in einer Erklärung ist am Anfang einer Zeile
  • JOIN und WHERE Kriterien unter erscheinen und sind eingerückt und ausgerichtet
  • Nested Artikel sind eingekerbte weiter
  • Ich benutze Aliase für alle Tabellen und Ansichten

Zum Beispiel:

SELECT 
    column_1, 
    column_2, 
    CASE 
     WHEN column_5 = 'Blah' THEN 1 
     WHEN column_6 = 'Blah' THEN 2 
     ELSE 3 
    END AS column_alias 
FROM 
    My_Table MT 
INNER JOIN My_Other_Table MOT ON 
    MOT.column_1 = MT.column_1 
WHERE 
    MT.column_2 = 'Some Value' AND 
    (
     MT.column_3 = 'Some other value' OR 
     MT.column_4 = 'Some other value' 
    ) 
+1

Ähnlich wie ich, aber ich würde den INNEREN JOIN (ohne INNER!) Mit Tabellen (es ist keine Majorklausel) und Bedingung in Einklang bringen. Wie auch immer, dieses allgemeine Layout ist eines der saubereren, die ich gesehen habe. – gbn

+0

Wahr ... vielleicht werde ich versuchen, die JOINs einzurücken und zu sehen, wie mir das gefällt. Ich mag es nicht, nur die Kriterien in die gleiche Zeile aufzunehmen, weil es oft ziemlich lang sein kann - und ich hasse das Scrollen nach links/rechts. Ich bevorzuge ein Kriterium in jeder Zeile. –

+1

Ich würde beginnen, die Kriterien einzurücken, wenn es lang war, aber es in einer Zeile halten, wenn es kurz ist: insbesondere "JOIN table1 ON table1.table1_id = table2.table1_id" ist der häufigste Fall bei weitem. Einige postgresql Voreingenommenheit hier, da das geschrieben werden kann "JOIN table1 USING (table1_id)" was dumm wäre zu teilen. – araqnid

2

ich folgen in der Regel diese Art von Syntax für MSSQL Server

SELECT statemenets

SELECT //optionally specify top or distinct 
    Field1, 
    Field2, 
    CASE WHEN (1 = 1) THEN 
     "1" 
    ELSE 
     "2" 
    END AS Field3, 
    ... 
FROM Table1 t1 
INNER JOIN Table2 t2 
    ON t2.field1 = t1.field1 //I always reference the joined tables field name first 
LEFT OUTER JOIN Table3 t3 
    ON (t3.field1 = t1.field1 
    AND t3.field2 = t2.field2) //I specify and with a new line and tabbed in 
    OR       // I specify or(s) on thier own line this way you can distinguish from the two conditionals that need to be met 
    (t3.field1 = t2.field1 
    AND t3.field2 = t1.field2) 
WHERE 
    (t1.Field1 = 'foo' 
    AND t1.field2 = 'bar') 
    OR 
    (t2.Field1 = 'foo' 
    AND t1.field2 = 'bar') 

abgeleitete Tabellen in einem Select

Select 
    Field1, 
    Field2, 
    ... 
FROM (Select 
      Field1, 
      Field2, 
      Field3) 
     FROM Table1 
     WHERE 
      Field1 = '1') t1 

Update-Anweisungen

UPDATE Table1 
    SET 
    Field1 = 1, 
    Field2 = 2, 
    Field3 = 3 
WHERE 
    (Field1 = 2 
    AND Field3 = 2) 
    OR 
    (Field3 = 1) 

Insert Statements

INSERT INTO Table1 
    (Field1, 
    Field2, 
    Field3, 
    ...) 
VALUES 
    (1, 
    2, 
    3, 
    ...) 

Wenn Statements

IF (some condition) BEGIN 
END ELSE BEGIN 
END 

Verfahren

CREATE PROCEDURE Foo (
    Bar INT, 
    Foo VARCHAR(20) 
) AS 
BEGIN 
    //Your Code Here 
END 
+0

Das finde ich unglaublich witzig. Die meisten Datenbanken benötigen weder "INNER" noch "OUTER" in der Join-Syntax, und eine Zeilenrückgabe für jedes Join-Kriterium ist Platzverschwendung, wenn ~ 80 Zeichen auf dem Bildschirm vorhanden sind. Die Verwendung dieses Formats ist für dynamisches SQL riskant, es sei denn, Sie verketten jede Zeile mit öffnenden und abschließenden Klauseln - zumindest für Oracle -, weil der Platz als absichtliche Zeichen interpretiert werden kann. –

+1

Ich bin froh, dass Sie erwähnt haben, zuerst auf den Feldnamen der verbundenen Tabelle zu verweisen. Ohne Klammern ist Ihre AND/OR-Logik ein wenig mehrdeutig. –

+0

@OMG Ponys. Ja, ich weiß, dass du das Innere und Äußere nicht brauchst, du kannst einfach JOIN statt INNER JOIN und LEFT JOIN anstelle von LEFT OUTER JOIN sagen. Es ist nur ein Habit, den ich geformt habe. –

0

ich die folgenden Regeln verwenden:

  • Immer in Großbuchstaben SQL reservierte Wörter (SELECT, FROM, WHERE, HABEN, UND ODER DISTINCT usw.
  • )

    Hässliche:
    select height,width,age from person where width = 20
    Tidy:
    SELECT height, width, age FROM person WHERE (width = 20)

  • Klein alle Tabellennamen. Verwenden Sie nie camelcase (donkeyWrench) in Tabellennamen (Sie werden sich in den Kopf schießen, wenn Sie die Abfragen von Hand erstellen).

  • Verwenden Sie bei WHERE- und HAVING-Klauseln immer Klammern. Verwenden Sie Leerzeichen zwischen Operatoren.

    Hässliche:
    ... where width=20 and height>20
    Tidy:
    WHERE (width = 20) AND (height > 20)

  • Aliase für Tabellennamen.
    SELECT * FROM donkeywrench dw ... `
  • Verwendung lesbar, name bezogenen Primärschlüsselfelder. Ich starte Schlüssel und Primärschlüssel immer mit 'id_'.
    Tabellenname: donkeywrench, Primärschlüssel: id_donkeywrench
  • Mark, wo die Abfrage stammt. Während Sie Protokolle lesen, können Sie leicht aufspüren, wo das Problem aufgetreten ist.
    /* Genannt aus donkeykong.php, Zeile 22 * ​​/ SELECT * FROM donkeywrench dw ...
  • Wenn die Abfrage loooong ist
    - Lassen Sie immer die Operator (UND, ODER) am Ende der Zeile
    - Verwenden Sie Klammern!

Beispiel:

/*Executed from xyz.php*/ 
SELECT 
p.height, p.width, p.age, 
pd.hastel, pd.hasmobile 

FROM 
person p 
LEFT JOIN personaldata pd ON p.id_person = pd.id_person 
LEFT JOIN relatives r ON pd.id_person = r.id_person 

WHERE 
(p.width = 20) AND 
((p.height > 20) AND (p.height < 15)) AND 
(pd.hastel) 

ORDER BY 
p.age, p.height 
+1

Ich stimme nicht mit den Klammern um WHERE Bedingungen überein. Wenn die Vorrangstellung des Bedieners klar ist, finde ich das störend. Es ist, als würde man den Ausdruck ((x * y) + (s * t))/z anstelle von (x * y + s * t)/z schreiben. Wenn es weniger Klammern gibt, ist es einfacher zu sehen, wie sie zusammenpassen. Natürlich ist dies eine Frage der Präferenz. –

4

Vielleicht s "Betrug";) - aber ich habe gerade eine erstaunliche Website, die dies für Sie erledigt!

http://poorsql.com

und die Optionen sind vollständig anpassbar

+0

Awesome Werkzeug, und kostenlos zu booten! – svrist

Verwandte Themen