Quels sont les anti-modèles SQL les plus courants? [fermé]

Tous ceux qui travaillent avec des bases de données relationnelles ont appris (ou apprennent) que SQL est différent. Obtenir les résultats souhaités, et le faire efficacement, implique un processus fastidieux en partie caractérisé par l'apprentissage de paradigmes inconnus et la découverte que certains de nos modèles de programmation les plus familiers ne fonctionnent pas ici. Quels sont les antipatterns courants que vous avez vus (ou que vous avez commis)?

Je suis constamment déçu par la tendance de la plupart des programmeurs à mélanger leur logique d'interface utilisateur dans la couche d'accès aux données:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Normalement, les programmeurs le font car ils ont l'intention de lier leur ensemble de données directement à une grille, et c'est tout simplement pratique d'avoir le format SQL Server côté serveur que le format sur le client.

Les requêtes comme celle illustrée ci-dessus sont extrêmement fragiles car elles couplent étroitement la couche de données à la couche d'interface utilisateur. En plus de cela, ce style de programmation empêche complètement les procédures stockées d'être réutilisables.

Voici mon top 3.

Numéro 1. Échec de la spécification d'une liste de champs. (Modifier: pour éviter toute confusion: il s'agit d'une règle de code de production. Elle ne s'applique pas aux scripts d'analyse uniques - sauf si je suis l'auteur.)

SELECT *
Insert Into blah SELECT *

devrait être

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Numéro 2. En utilisant un curseur et une boucle while, quand une boucle while avec une variable de boucle fera l'affaire.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Numéro 3. DateLogic à travers les types de chaînes.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Devrait être

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

J'ai récemment vu un pic de "Une requête vaut mieux que deux, d'accord?"

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Cette requête nécessite deux ou trois plans d'exécution différents selon les valeurs des paramètres. Un seul plan d'exécution est généré et bloqué dans le cache pour ce texte SQL. Ce plan sera utilisé quelle que soit la valeur des paramètres. Il en résulte des performances médiocres intermittentes. Il est préférable d'écrire deux requêtes (une requête par plan d'exécution prévu).

• Champs de mot de passe lisibles par l'homme , egad. Explicite.

• Utiliser LIKE contre des colonnes indexées , et je suis presque tenté de dire LIKE en général.

• Recyclage des valeurs PK générées par SQL.

• Surprise, personne n'a encore mentionné la table divine. Rien ne dit "organique" comme 100 colonnes de drapeaux de bits, de grandes chaînes et des entiers.

• Ensuite, il y a le modèle «Les fichiers .ini me manquent» : stockage de fichiers CSV, de chaînes délimitées par des tuyaux ou d'autres données d'analyse requises dans de grands champs de texte.

• Et pour MS SQL Server, l'utilisation de curseurs du tout . Il existe une meilleure façon d'effectuer une tâche de curseur donnée.

Modifié parce qu'il y en a tellement!

Pas besoin de creuser profondément pour cela: ne pas utiliser de déclarations préparées.

Utilisation d'alias de table sans signification:

from employee t1,
department t2,
job t3,
...

Rend la lecture d'une grande instruction SQL beaucoup plus difficile qu'elle ne devrait l'être

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Confiance aveugle à l'utilisateur
2. Ne pas utiliser de requêtes paramétrées
3. Mots de passe en texte clair

Mes bugbears sont les 450 tables d'accès de colonne qui ont été rassemblées par le fils de 8 ans du meilleur toiletteur pour chiens du directeur général et la table de recherche douteuse qui n'existe que parce que quelqu'un ne sait pas normaliser correctement une infrastructure de données.

En règle générale, cette table de recherche ressemble à ceci:

ID INT,
Nom NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Date1 DATETIME,
Date2 DATETIME

J'ai perdu le compte du nombre de clients que j'ai vus qui ont des systèmes qui reposent sur des abominations comme celle-ci.

Ceux que je déteste le plus sont

1. Utilisation d'espaces lors de la création de tableaux, de sprocs, etc. J'ai rencontré ça) m'irrite vraiment.

2. Données dénormalisées. Un tableau n'a pas besoin d'être parfaitement normalisé, mais lorsque je rencontre un tableau d'employés qui a des informations sur leur score d'évaluation actuel ou leur principal élément, il me dit que je devrai probablement créer un tableau séparé à un moment donné et essayez ensuite de les garder synchronisés. Je normaliserai d'abord les données, puis si je vois un endroit où la dénormalisation aide, je l'envisagerai.

3. Surutilisation des vues ou des curseurs. Les vues ont un but, mais lorsque chaque table est enveloppée dans une vue, c'est trop. J'ai dû utiliser des curseurs à quelques reprises, mais en général, vous pouvez utiliser d'autres mécanismes pour cela.

4. Accès. Un programme peut-il être un anti-modèle? Nous avons SQL Server à mon travail, mais un certain nombre de personnes utilisent l'accès en raison de sa disponibilité, de sa «facilité d'utilisation» et de sa «convivialité» pour les utilisateurs non techniques. Il y a trop de choses ici, mais si vous avez été dans un environnement similaire, vous savez.

utilisez SP comme préfixe du nom de la procédure de stockage car il recherchera d'abord dans l'emplacement des procédures système plutôt que dans les personnalisées.

Surutilisation des tables temporaires et des curseurs.

Pour stocker les valeurs d'heure, seul le fuseau horaire UTC doit être utilisé. L'heure locale ne doit pas être utilisée.

en utilisant @@ IDENTITY au lieu de SCOPE_IDENTITY ()

Cité de cette réponse :

• @@ IDENTITY renvoie la dernière valeur d'identité générée pour n'importe quelle table de la session en cours, sur toutes les étendues. Vous devez être prudent ici, car il s'agit de plusieurs étendues. Vous pouvez obtenir une valeur à partir d'un déclencheur, au lieu de votre instruction actuelle.
• SCOPE_IDENTITY renvoie la dernière valeur d'identité générée pour n'importe quelle table de la session en cours et la portée en cours. Généralement ce que vous souhaitez utiliser.
• IDENT_CURRENT renvoie la dernière valeur d'identité générée pour une table spécifique dans une session et une étendue. Cela vous permet de spécifier de quelle table vous voulez que la valeur provienne, au cas où les deux ci-dessus ne seraient pas tout à fait ce dont vous avez besoin (très rare). Vous pouvez l'utiliser si vous souhaitez obtenir la valeur IDENTITY actuelle pour une table dans laquelle vous n'avez pas inséré d'enregistrement.

Réutiliser un champ «mort» pour quelque chose auquel il n'était pas destiné (par exemple, stocker des données utilisateur dans un champ «Fax») - très tentant cependant comme solution rapide!

select some_column, ...
from some_table
group by some_column

et en supposant que le résultat sera trié par some_column. J'ai vu cela un peu avec Sybase où l'hypothèse est vraie (pour l'instant).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Ou, tout entasser en une seule ligne.

• La FROM TableA, TableB WHEREsyntaxe pour JOINS plutôt queFROM TableA INNER JOIN TableB ON

• Le fait de supposer qu'une requête sera renvoyée est trié d'une certaine manière sans insérer de clause ORDER BY, simplement parce que c'est ainsi qu'il est apparu lors des tests dans l'outil de requête.

Apprendre le SQL au cours des six premiers mois de sa carrière et ne jamais rien apprendre d'autre au cours des 10 prochaines années. En particulier, ne pas apprendre ou utiliser efficacement les fonctionnalités de fenêtrage / analytique SQL. En particulier l'utilisation de over () et de la partition par.

Les fonctions de fenêtre, comme les fonctions d'agrégation, effectuent une agrégation sur un ensemble défini (un groupe) de lignes, mais plutôt que de renvoyer une valeur par groupe, les fonctions de fenêtre peuvent renvoyer plusieurs valeurs pour chaque groupe.

Voir O'Reilly SQL Cookbook Annexe A pour un bon aperçu des fonctions de fenêtrage.

Je dois mettre mon propre favori actuel ici, juste pour compléter la liste. Mon antipattern préféré ne teste pas vos requêtes .

Cela s'applique lorsque:

1. Votre requête implique plusieurs tables.
2. Vous pensez avoir une conception optimale pour une requête, mais ne vous embêtez pas à tester vos hypothèses.
3. Vous acceptez la première requête qui fonctionne, sans aucun indice quant à son optimisation.

Et tout test exécuté contre des données atypiques ou insuffisantes ne compte pas. S'il s'agit d'une procédure stockée, mettez l'instruction de test dans un commentaire et enregistrez-la avec les résultats. Sinon, mettez-le dans un commentaire dans le code avec les résultats.

Abus de table temporaire.

Plus précisément ce genre de chose:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Ne créez pas de table temporaire à partir d'une requête, uniquement pour supprimer les lignes dont vous n'avez pas besoin.

Et oui, j'ai vu des pages de code sous cette forme dans des bases de données de production.

Point de vue contraire: obsession excessive de la normalisation.

La plupart des systèmes SQL / RBDB offrent de nombreuses fonctionnalités (transactions, réplication) qui sont très utiles, même avec des données non normalisées. L'espace disque est bon marché, et parfois il peut être plus simple (code plus facile, temps de développement plus rapide) de manipuler / filtrer / rechercher les données récupérées, que d'écrire le schéma 1NF, et de gérer tous les tracas qu'il contient (jointures complexes, sous-sélections désagréables , etc).

J'ai trouvé que les systèmes sur-normalisés sont souvent une optimisation prématurée, en particulier pendant les premiers stades de développement.

(plus de réflexions à ce sujet ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Je viens de mettre celui-ci ensemble, basé sur certaines des réponses SQL ici sur SO.

C'est un contre-modèle sérieux de penser que les déclencheurs sont aux bases de données comme les gestionnaires d'événements le sont à la POO. Il y a cette perception que n'importe quelle ancienne logique peut être insérée dans des déclencheurs, pour être déclenchée lorsqu'une transaction (événement) se produit sur une table.

Pas vrai. L'une des grandes différences est que les déclencheurs sont synchrones - avec une vengeance, car ils sont synchrones sur une opération définie, et non sur une opération de ligne. Du côté de la POO, exactement le contraire - les événements sont un moyen efficace d'implémenter des transactions asynchrones.

Procédures ou fonctions stockées sans aucun commentaire ...

1) Je ne sais pas que c'est un anti-modèle "officiel", mais je n'aime pas et j'essaye d'éviter les littéraux de chaîne comme valeurs magiques dans une colonne de base de données.

Un exemple de la table 'image' de MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Je remarque juste un boîtier différent, une autre chose à éviter)

Je conçois des cas tels que des recherches int dans les tableaux ImageMediaType et ImageMajorMime avec des clés primaires int.

2) conversion de date / chaîne qui repose sur des paramètres NLS spécifiques

CONVERT(NVARCHAR, GETDATE())

sans identificateur de format

Sous-requêtes identiques dans une requête.

• La vue modifiée - Une vue qui est modifiée trop souvent et sans préavis ni raison. Le changement sera soit remarqué au moment le plus inapproprié, soit pire se trompera et ne sera jamais remarqué. Peut-être que votre application sera interrompue parce que quelqu'un a pensé à un meilleur nom pour cette colonne. En règle générale, les vues devraient étendre l'utilité des tables de base tout en conservant un contrat avec les consommateurs. Résolvez les problèmes mais n'ajoutez pas de fonctionnalités ou pire changement de comportement, pour cela créez une nouvelle vue. Pour atténuer, ne partagez pas les vues avec d'autres projets et utilisez les CTE lorsque les plateformes le permettent. Si votre boutique dispose d'un DBA, vous ne pouvez probablement pas changer de vue, mais toutes vos vues seront obsolètes et / ou inutiles dans ce cas.

• Le! Paramed - Une requête peut-elle avoir plusieurs objectifs? Probablement, mais la prochaine personne qui le lira ne le saura pas avant une profonde méditation. Même si vous n'en avez pas besoin maintenant, il y a de fortes chances que vous le fassiez, même si c'est "juste" pour déboguer. L'ajout de paramètres réduit le temps de maintenance et garde les choses au SEC. Si vous avez une clause where, vous devez avoir des paramètres.

• Le cas sans CAS -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

Les deux que je trouve le plus, et qui peuvent avoir un coût significatif en termes de performances sont:

• Utiliser des curseurs au lieu d'une expression basée sur un ensemble. Je suppose que celui-ci se produit fréquemment lorsque le programmeur réfléchit de manière procédurale.

• À l'aide de sous-requêtes corrélées, lorsqu'une jointure à une table dérivée peut faire le travail.

Placer des éléments dans des tables temporaires, en particulier les personnes qui passent de SQL Server à Oracle, ont l'habitude de trop utiliser les tables temporaires. Utilisez simplement des instructions select imbriquées.

Les développeurs qui écrivent des requêtes sans avoir une bonne idée de ce qui rend les applications SQL (à la fois les requêtes individuelles et les systèmes multi-utilisateurs) rapides ou lentes. Cela comprend l'ignorance de:

• stratégies de minimisation des E / S physiques, étant donné que le goulot d'étranglement de la plupart des requêtes est E / S et non CPU
• impact de différents types d'accès au stockage physique (par exemple, de nombreuses E / S séquentielles seront plus rapides que de nombreuses petites E / S aléatoires, mais moins si votre stockage physique est un SSD!)
• comment régler manuellement une requête si le SGBD produit un mauvais plan de requête
• comment diagnostiquer les performances médiocres de la base de données, comment «déboguer» une requête lente et comment lire un plan de requête (ou EXPLAIN, selon le SGBD de votre choix)
• stratégies de verrouillage pour optimiser le débit et éviter les blocages dans les applications multi-utilisateurs
• importance du traitement par lots et d'autres astuces pour gérer le traitement des ensembles de données
• conception de tables et d'index pour équilibrer au mieux l'espace et les performances (par exemple, couvrir les index, garder les index petits dans la mesure du possible, réduire les types de données à la taille minimale requise, etc.)

Utilisation de SQL comme package ISAM (méthode d'accès séquentiel indexé) glorifié. En particulier, imbriquer des curseurs au lieu de combiner des instructions SQL en une seule instruction, quoique plus volumineuse. Cela compte également comme «abus de l'optimiseur» car en fait, l'optimiseur ne peut pas faire grand-chose. Cela peut être combiné avec des déclarations non préparées pour une inefficacité maximale:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

La solution correcte (presque toujours) consiste à combiner les deux instructions SELECT en une seule:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Le seul avantage de la version à double boucle est que vous pouvez facilement repérer les ruptures entre les valeurs du tableau 1 car la boucle interne se termine. Cela peut être un facteur dans les rapports de rupture de contrôle.

En outre, le tri dans l'application est généralement un non-non.

Utilisation de clés primaires comme substitut pour les adresses d'enregistrement et utilisation de clés étrangères comme substitut pour les pointeurs intégrés aux enregistrements.