Pourriez-vous énumérer certaines des mauvaises pratiques en SQL, que les gens novices font?
J'ai trouvé l'utilisation de "tandis que la boucle" dans des scénarios pouvant être résolues à l'aide d'opérations définies.
Un autre exemple est l'insertion de données uniquement si cela n'existe pas. Cela peut être atteint en utilisant une jointure extérieure gauche. Certaines personnes vont pour "si"
Toute autre pensées?
Edit: Ce que je recherche est des scénarios spécifiques (comme mentionné dans la question) qui pourraient être atteints à l'aide de SQL sans utiliser des constructions de procédure
merci
lijo
5 Réponses :
Voici certains que j'ai vu:
(n) hibernate fait des jointures extérieures par défaut -_-
Je envisagerais d'insérer NULL pour être une odeur de code pour la conception de schéma. Si vous devez tout vérifier pour NULL tout le temps, votre code peut devenir assez moche et difficile à suivre.
Personnellement pour moi: tout ce qui n'est pas un insertion simple, mettez à jour, supprimer ou sélectionner une instruction
Je n'aime pas la logique dans SQL.
C'est ironique, étant donné que SQL est fondé sur la logique du prédicat. Peut-être devriez-vous qualifier cette déclaration (avez-vous voulu dire: "Pas de curseurs", ou quelque chose comme ça?).
Je suppose que vous n'avez pas travaillé avec de grands ensembles de données dans un environnement d'entreprise. Pas que je ne suis pas d'accord tout à fait, mais parfois c'est la meilleure solution.
Je pense que la logique à l'intérieur de SQL est inévitable lorsque vous travaillez avec des rapports.
Code Logic est bien dans SQL, je pense que la logique commerciale dans SQL est mauvaise ... Vous allez maintenant demander un exemple: la logique implique normalement si des déclarations par exemple que certaines personnes essaient et évitent dans SQL, nous avons par exemple convertir le GUID. Les valeurs .ÉMETTY {00000 ....} à NULL dans le cadre de nos scripts SQL générés par notre code
Mon plus grand bœuf ici est définitivement répétitif SQL. À titre d'exemple, plusieurs procédures stockées qui effectuent exactement les mêmes jointures, mais différents filtres.
Utiliser des vues Dans de tels cas, vous pouvez rendre votre base de données beaucoup plus facile à regarder et à travailler avec
Pourriez-vous s'il vous plaît donner un exemple qui ne peut être réalisé qu'à l'aide de requêtes répétitives, si nous utilisons une proécurité stockée? [La même chose peut être obtenue sans répétition lorsqu'il est utilisé des vues]
Placer les appels ODBC ou SQL dynamique sur tout le code.
Il est souvent préférable de définir une couche d'abstraction de données qui fournit un accès aux bases de données. Tout le code SQL peut se cacher dans cette couche. Cela évite souvent la réplication de requêtes similaires et fait changer Les modèles de données plus faciles à faire.
Création de SQL spécifique au fournisseur, lorsque SQL générique ferait.
Création de tables de manière dynamique à l'exécution (autre que les tables temporaires).
Le fait de laisser votre code d'application contient une table Créer ou Super User Privs.
Cela devrait (au moins) être wiki communautaire
Notez qu'un "tandis que la boucle" n'est pas strictement SQL - c'est une construction dans certaines langues de vulgarisation procédurales.
@mkj - J'accepte votre point de vue. Ma question est aussi la même. Ce que je cherche, ce sont des scénarios spécifiques (comme mentionné dans ma question) qui pourraient être atteints à l'aide de SQL sans utiliser de constructions de procédure.