Normes de formatage SQL

Question

Dans mon dernier emploi, nous avons travaillé sur une base de données d'une application intense et j'ai développé une certaine mise en forme de normes, de sorte que nous sommes tous d'écrire du SQL avec une mise en commun. Nous avons également élaboré des normes de codage, mais ceux-ci sont plus spécifiques de la plateforme, donc je ne vais pas entrer dans les ici.

Je suis curieux de savoir ce que d'autres personnes utiliser SQL normes de formatage. Contrairement à la plupart des autres de codage des environnements que je n'ai pas trouvé un consensus en ligne pour eux.

Afin de couvrir les principaux types de requêtes:

select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from 
    SourceTable ST
inner join JoinTable JT
    on JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT
    on ST.SourceTableID = SJT.SourceTableID
    and JT.Column3 = SJT.Column4
where
    ST.SourceTableID = X
    and JT.ColumnName3 = Y

Il y a un certain désaccord au sujet des retours à la ligne après "select", "de" et "où". L'intention sur la ligne sélectionner est de permettre à d'autres opérateurs tels que "top X" sans modifier la mise en page. Ensuite, il suffit de garder une cohérence de saut de ligne après que la clé de la requête éléments, semblait résulter un bon niveau de lisibilité.

Déposer le saut de ligne après le "de" et "où" serait compréhensible de révision. Toutefois, dans les requêtes telles que la "mise à jour" ci-dessous, nous voyons que le saut de ligne après le "où" nous donne un bon alignement de la colonne. De même, un saut de ligne après le "groupe" ou "order by" garde de nos mises en page en colonnes clair et facile à lire.

update
    TargetTable
set
    ColumnName1 = @value,
    ColumnName2 = @value2
where
    Condition1 = @test

Enfin un insert:

insert into TargetTable (
    ColumnName1,
    ColumnName2,
    ColumnName3
) values (
    @value1,
    @value2,
    @value3
)

La plupart de ces ne pas s'écarter loin de la façon de MS SQL Server Directions Studio / query analyser écrire SQL, cependant, ils ne diffèrent.

J'ai hâte de voir si il y a un consensus dans le Débordement de la Pile de la communauté sur ce sujet. Je suis constamment étonné de voir comment de nombreux développeurs peuvent suivre les directives de mise en forme pour les autres langues, et tout à coup aller de manière aléatoire lors de la frappe SQL.

Answer 1

Réponse tardive mais je l'espère utile

Mon expérience de travail dans le cadre de la plus grande équipe de développement, c'est que vous pouvez aller de l'avant et de définir toutes les normes que vous voulez, mais le problème est en fait l'application des présentes ou qui le rend très facile pour les développeurs de mettre en œuvre.

En tant que développeurs, nous avons parfois de créer quelque chose qui fonctionne et ensuite dire "je vais le formater plus tard", mais que, plus tard, ne vient jamais.

Au début nous avons utilisé Invite SQL (c'était génial), mais ensuite passé à ApexSQL Refactoriser parce que c'est un outil gratuit.

Answer 2

Je suis d'avis que, aussi longtemps que vous pouvez lire le code source facilement, la mise en forme est secondaire. Tant que cet objectif est atteint, il y a un certain nombre de styles de mise en page qui peut être adopté.

Le seul autre aspect qui est important pour moi, c'est que, quel que soit le codage de mise en page/le style que vous choisissez d'adopter dans votre boutique, s'assurer qu'il est utilisé de façon uniforme par tous les codeurs.

Juste pour votre référence, voici comment j'allais présenter l'exemple que vous avez fourni, juste ma mise en page des préférences. De noter en particulier, la clause est sur la même ligne que la jointure, seulement la principale condition de jointure est répertorié dans la jointure (j'.e la clé du match) et d'autres conditions sont déplacés à l'endroit où cluase.

select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from 
    SourceTable ST
inner join JoinTable JT on 
    JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT on 
    ST.SourceTableID = SJT.SourceTableID
where
        ST.SourceTableID = X
    and JT.ColumnName3 = Y
    and JT.Column3 = SJT.Column4

Un conseil, procurez-vous une copie de SQL Invite de commandes à partir de Porte Rouge. Vous pouvez personnaliser l'outil à utiliser votre disposition souhaitée préférences, puis les codeurs dans votre boutique peut tous les utiliser pour vous assurer le même codage des normes sont adoptées par tout le monde.

Cheers, John

Answer 3

Je suis en retard à la fête, mais je vais juste ajouter mon préféré style de mise en forme, qui je dois l'ai appris dans les livres et les manuels: il est compact. Voici l'exemple d' SELECT déclaration:

SELECT  st.column_name_1, jt.column_name_2,
        sjt.column_name_3
FROM    source_table AS st
        INNER JOIN join_table AS jt USING (source_table_id)
        INNER JOIN second_join_table AS sjt ON st.source_table_id = sjt.source_table_id
                AND jt.column_3 = sjt.column_4
WHERE   st.source_table_id = X
AND     jt.column_name_3 = Y

En bref: 8-l'espace de l'indentation, des mots-clés en majuscules (même SI les couleurs de leur mieux quand en minuscules), pas de camelcase (inutile sur Oracle), et la ligne continue en cas de besoin.

L' UPDATE:

UPDATE  target_table
SET     column_name_1 = @value,
        column_name_2 = @value2
WHERE   condition_1 = @test

Et l' INSERT:

INSERT  INTO target_table (column_name_1, column_name_2,
                column_name_3)
VALUES  (@value1, @value2, @value3)

Maintenant, laissez-moi être le premier à admettre que ce style a ses problèmes. 8-espace tiret signifie qu' ORDER BY et GROUP BY soit un mauvais alignement, le retrait, ou de diviser le mot BY off par lui-même. Il serait plus naturel de retrait de l'ensemble du prédicat de l' WHERE de la clause, mais j'ai l'habitude d'aligner suivant AND et OR opérateurs à la marge de gauche. La mise en retrait après avoir enveloppé INNER JOIN des lignes est aussi quelque peu arbitraire.

Mais pour quelque raison que ce soit, je trouve encore plus facile à lire que les solutions de rechange.

Je vais en finir avec l'un de mes plus complexe créations de la fin de l'utilisation de ce style de mise en forme. Assez bien tout ce que vous pouvez rencontrer dans une SELECT déclaration montre que dans celui-ci. (Il a aussi été modifié pour dissimuler ses origines, et je peut avoir introduit des erreurs dans le faire.)

SELECT  term, student_id,
        CASE
            WHEN ((ft_credits > 0 AND credits >= ft_credits) OR (ft_hours_per_week > 3 AND hours_per_week >= ft_hours_per_week)) THEN 'F'
            ELSE 'P'
        END AS status
FROM    (
        SELECT  term, student_id,
                pm.credits AS ft_credits, pm.hours AS ft_hours_per_week,
                SUM(credits) AS credits, SUM(hours_per_week) AS hours_per_week
        FROM    (
                SELECT  e.term, e.student_id, NVL(o.credits, 0) credits,
                        CASE
                            WHEN NVL(o.weeks, 0) > 5 THEN (NVL(o.lect_hours, 0) + NVL(o.lab_hours, 0) + NVL(o.ext_hours, 0)) / NVL(o.weeks, 0)
                            ELSE 0
                        END AS hours_per_week
                FROM    enrollment AS e
                        INNER JOIN offering AS o USING (term, offering_id)
                        INNER JOIN program_enrollment AS pe ON e.student_id = pe.student_id AND e.term = pe.term AND e.offering_id = pe.offering_id
                WHERE   e.registration_code NOT IN ('A7', 'D0', 'WL')
                )
                INNER JOIN student_history AS sh USING (student_id)
                INNER JOIN program_major AS pm ON sh.major_code_1 = pm._major_code AND sh.division_code_1 = pm.division_code
        WHERE   sh.eff_term = (
                        SELECT  MAX(eff_term)
                        FROM    student_history AS shi
                        WHERE   sh.student_id = shi.student_id
                        AND     shi.eff_term <= term)
        GROUP   BY term, student_id, pm.credits, pm.hours
        )
ORDER   BY term, student_id

Cette abomination calcule si l'étudiant est à temps plein ou à temps partiel dans une période de temps donnée. Quel que soit le style, celui-ci est difficile à lire.

Answer 4

Nice. En tant que programmeur Python, voici mes préférences:

Les retours à la ligne après "select", "de" et "où" seulement lorsque c'est nécessaire pour des raisons de lisibilité.

Lorsque le code code peut être plus compact et tout aussi lisible, je préfère la forme plus compacte. Être en mesure de tenir plus de code dans un seul écran améliore la productivité.

select ST.ColumnName1, JT.ColumnName2, SJT.ColumnName3
from SourceTable ST
inner join JoinTable JT
    on JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT
    on ST.SourceTableID = SJT.SourceTableID
    and JT.Column3 = SJT.Column4
where ST.SourceTableID = X and JT.ColumnName3 = Y

En fin de compte, ce sera un jugement d'appel, qui seront réalisés au cours de l'examen du code.

Pour insert, je mets en place les parens différemment:

insert into TargetTable (
    ColumnName1,
    ColumnName2,
    ColumnName3)
values (
    @value1,
    @value2,
    @value3)

La raison de cette mise en forme est que si SQL utilisé idendation pour la structure de bloc (comme Python), puis la parenthèse ne seraient pas nécessaires. Donc, si l'indentation est utilisé de toute façon, alors parens doivent avoir le minimum d'effet sur la mise en page. Ceci est réalisé en plaçant à la fin des lignes.

Answer 5

J'ai tendance à utiliser une mise en page similaire à la votre bien que j'aille même quelques pas plus loin, par exemple: -

 select
        ST.ColumnName1
    ,   JT.ColumnName2
    ,   SJT.ColumnName3
from
                SourceTable     ST

    inner join  JoinTable       JT
        on  JT.SourceTableID    =   ST.SourceTableID

    inner join  SecondJoinTable SJT
        on  ST.SourceTableID    =   SJT.SourceTableID

where
        ST.SourceTableID    =   X
    and JT.ColumnName3      =   Y
    and JT.Column3          =   SJT.Column4
 

Cela semble peut-être un peu exagéré au début, mais à mon humble avis, l’utilisation de la tabulation de cette manière donne la mise en page la plus propre et la plus systématique compte tenu de la nature déclarative de SQL.

Vous allez probablement vous retrouver avec toutes sortes de réponses ici, à la fin c'est une préférence personnelle ou convenue par l'équipe.