Formatage de code requêtes SQL

Dois-je interrompre les requêtes SQL sur différentes lignes? Par exemple, dans le projet sur lequel je travaille, nous avons une requête qui prend 1600 colonnes! 1600 + tab tabs. J'ai écrit des requêtes comme celle-ci:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Mais ils m'ont demandé de les mettre sur une seule ligne et ont dit que mon style est un mauvais formatage. Pourquoi est-ce une mauvaise pratique?

Pour des raisons de contrôle de code source, nous avons des sauts de ligne après chaque clause where ou virgule. Donc, votre dessus se transforme en

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(tabulation et alignement n'a pas de norme ici, mais les virgules sont généralement en tête)

Pourtant, cela ne fait aucune différence de performances.

Une requête de 1600 colonnes semble nécessiter un examen sérieux par un bon DBA.

Si une requête est complexe, je la terminerai. Si c'est simple, je le laisserai sur une seule ligne à moins que ça ne soit trop long, alors je recommencerai à envelopper.

Tout est question de gérabilité et de compréhension de ce qu'il est censé faire. L'habillage ou non peut être décidé à la volée, à moins que votre organisation n'ait des règles de formatage de code à ce sujet.

Re: c'est une mauvaise pratique de codage. À peine! C'est une très bonne pratique. Je ne connais aucune bonne raison d'utiliser une requête aussi longue et de nombreuses bonnes raisons de la reformater. Comme je l'ai déjà dit, un DBA qualifié doit probablement y travailler.

Le seul avantage des requêtes sur une seule ligne qui me vient à l'esprit est que ces requêtes peuvent être un peu plus faciles à comprendre. À part ça, je suis perplexe. Personnellement, je préfère les requêtes fractionnées plus lisibles.

Les commentaires multilignes sont bons, presque essentiels lorsqu'ils traitent de gros volumes de SQL. Et si votre langage de programmation contient des citations héréditaires, c'est encore mieux (car de nombreux éditeurs peuvent y mettre en évidence la syntaxe SQL).

Exemple:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Lorsque vous travaillez avec des requêtes de dizaines de lignes (ou de centaines), le retrait et les espaces rendent le texte réalisable.

Il semble qu'il s'agisse spécifiquement de définir une grande requête dans un langage de programmation, en vous voyant mettre la requête dans un littéral de chaîne et la concaténer.

S'il s'agit d'un langage compilé, cela ne devrait faire aucune différence - l'une des premières optimisations que le compilateur ferait serait de concaténer automatiquement les littéraux de chaîne ensemble, de sorte que vous vous retrouvez avec une grosse chaîne de toute façon.

En ce qui concerne la syntaxe, vous devriez réellement envisager de déplacer la requête en dehors de votre code - stockez-la dans un fichier de ressources .sql distinct et demandez à votre logiciel de lire ce fichier. Utilisez des instructions préparées pour les variables, si ce n'est pas une requête qui est construite dynamiquement (c'est-à-dire des clauses where etc. ajoutées en fonction de certains paramètres). S'il est construit dynamiquement, vous pouvez ajouter vos propres variables de remplacement, en insérant des paramètres supplémentaires où et quand vous en avez besoin.

En ce qui concerne les 1600 colonnes, je recommande sérieusement de créer une vue pour cela, donc au lieu de

SELECT column1, column2, .... column1600 from X where Y

tu aurais

SELECT * FROM viewX O y y

Beaucoup plus concis dans votre propre code.

J'utilise souvent le format proposé par @glasnt pour dépanner une requête compliquée, mais j'ai généralement des requêtes sur une seule ligne.

Cela pourrait ne pas répondre à votre question, mais je vous suggère également de décomposer votre requête en requêtes plus petites. Évidemment, cela dépend de la requête, mais plus vous ajoutez de clauses et de jointures à votre requête, moins le moteur SQL est en mesure d'optimiser votre requête.

Votre fournisseur de base de données devrait avoir des outils comme EXPLAIN de MySQL (ou le paramètre SHOWPLAN_ALL de MSSQL) qui vous montreront ce que la base de données fait en coulisses pour optimiser votre requête, chaque fois que la base de données doit créer une table temporaire ou quelque chose du genre, vous ajoutez d'énormes retards lorsque vous parlez de plusieurs utilisateurs simultanés.

En déplaçant ce qui peut sembler être une logique triviale hors du SQL et dans votre code, vous pouvez augmenter considérablement les performances - SQL est parfait pour les opérations simples.

L'avantage évident, car cela pourrait vous concerner, est que vos requêtes sont beaucoup moins complexes et faciles à lire - faciles à gérer (pas> 1600 colonnes) et plus rapides. Certainement une victoire tous azimuts.

J'espère que cela t'aides :)