Développement de bases de données erreurs commises par les développeurs d'applications [fermé]

quelles sont les erreurs courantes de développement de base de données faites par les développeurs d'applications?

566
demandé sur Charles Faiga 2009-03-07 17:12:06
la source

30 ответов

1. N'utilisant pas les indices appropriés

c'est relativement facile mais cela arrive tout le temps. Les clés étrangères doivent avoir des index. Si vous utilisez un champ dans un WHERE vous devriez (probablement) avoir un index dessus. Ces indices portent souvent sur plusieurs colonnes basées sur les requêtes que vous devez exécuter.

2. Ne pas appliquer l'intégrité référentielle

votre base de données peut varier ici, mais si votre base de données prend en charge l'intégrité référentielle--ce qui signifie que toutes les clés étrangères sont garanties pour pointer vers une entité qui existe--vous devriez l'utiliser.

il est assez courant de voir cet échec sur les bases de données MySQL. Je ne crois pas que MyISAM le supporte. InnoDB si. Vous trouverez des personnes qui utilisent MyISAM ou ceux qui utilisent InnoDB mais ne l'utilisent pas de toute façon.

plus ici:

3. L'utilisation de naturel plutôt que clefs primaires (techniques) de substitution

les clés naturelles sont des clés basées sur des données externes significatives qui sont (ostensiblement) uniques. Les codes produits, les codes d'État à deux lettres (US), les numéros de sécurité sociale, etc. sont des exemples courants. Les clés primaires de substitution ou techniques sont celles qui n'ont absolument aucun sens en dehors du système. Ils sont inventés uniquement pour identifier l'entité et sont typiquement des champs à incrémentation automatique (SQL Server, MySQL, autres) ou séquences (notamment Oracle).

à mon avis, vous devriez toujours utiliser des clés de remplacement. Cette question a été soulevée dans ces questions:

c'est un sujet quelque peu controversé sur lequel vous n'obtiendrez pas d'accord universel. Alors que vous pouvez trouver des personnes, qui pensent que les clés naturelles sont dans certaines situations OK, vous ne trouverez pas de critique des clés de substitution autre que d'être sans doute inutile. C'est un petit inconvénient si vous voulez mon avis.

Rappelez-vous, même pays peut cesser d'exister (par exemple, la Yougoslavie).

4. Écrire des requêtes qui nécessitent DISTINCT pour travailler

vous le voyez souvent dans les requêtes générées par ORM. Regardez la sortie de journal de hibernation et vous verrez toutes les requêtes commencer par:

SELECT DISTINCT ...

C'est un raccourci pour s'assurer que vous ne retournez pas les lignes dupliquées et obtenez ainsi des objets dupliqués. Vous verrez parfois des gens faire ça aussi. Si vous voyez trop, c'est un vrai drapeau rouge. Non pas que DISTINCT soit mauvais ou n'ait pas d'applications valables. Il le fait (sur les deux points), mais ce n'est pas un substitut ou un palliatif pour écrire des requêtes correctes.

à Partir de Pourquoi je Déteste DISTINCTES :

où les choses commencent à se gâter dans mon l'opinion, c'est quand un développeur construire une requête substantielle, joindre tables, et tout d'un coup il se rend compte qu'il regarde comme il est obtention de lignes dupliquées (ou même plus) et sa réponse immédiate...son "la solution" à ce "problème" est de jetez sur le mot-clé DISTINCT et POOF tous ses problèmes disparaissent.

5. Favoriser agrégation sur jointures

une autre erreur courante par les développeurs d'applications de base de données est de ne pas réaliser à quel point l'agrégation plus coûteuse (c'est-à-dire la clause GROUP BY ) peut être comparée à des jointures.

pour vous donner une idée de l'étendue de ce sujet, j'ai écrit sur ce sujet à plusieurs reprises ici et a été beaucoup rétrogradé pour elle. Par exemple:

à Partir de instruction SQL - "joindre" vs "group by et ayant " :

première requête:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

moment de la Requête: 0.312 s

Deuxième requête:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

moment de la Requête: 0.016 s

c'est exact. La version de jointure I proposé est vingt fois plus rapide que la version agrégée.

6. Pas simplifier les requêtes complexes à travers les vues

tous les fournisseurs de bases de données ne prennent pas en charge les vues, mais pour ceux qui le font, ils peuvent grandement simplifier les requêtes si elles sont utilisées judicieusement. Par exemple, sur un projet, j'ai utilisé un modèle de partie générique pour le CRM. Il s'agit d'une technique de modélisation extrêmement puissante et flexible, mais qui peut conduire à de nombreuses jointures. Dans ce modèle il y avait:

  • parti : personnes et organisations;
  • Rôle de la Partie : tout ce que les parties n'ont, par exemple de l'Employé et de l'Employeur;
  • Rôle de la Partie de la Relation : comment ces rôles liés les uns aux autres.

exemple:

  • Ted est une Personne, d'être un sous-type de Partie;
  • Ted a plusieurs rôles, dont celui D'employé;
  • Intel est une organisation, étant un sous-type d'une Partie;
  • Intel a de nombreux rôles, dont l'une est l'Employeur;
  • Intel emploie Ted, ce qui signifie qu'il existe une relation entre leurs rôles respectifs.

il y a donc cinq tables jointes pour relier Ted à son employeur. Vous supposez que tous les employés sont des personnes (et non des organisations) et vous fournissez cette vue d'aide:

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

et soudainement, vous avez une vue très simple des données que vous voulez mais sur un modèle de données très flexible.

7. Non aseptisé input

C'est un énorme. Maintenant J'aime PHP mais si vous ne savez pas ce que vous faites, il est vraiment facile de créer des sites vulnérables à l'attaque. Rien ne résume mieux que le de little Bobby Tables .

données fournies par l'utilisateur au moyen de Les URLs, les données de forme et les cookies doivent toujours être traités comme hostiles et aseptisés. Assurez-vous que vous obtenez ce que vous attendez.

8. N'utilisant pas les déclarations préparées

déclarations préparées sont lorsque vous compilez une requête moins les données utilisées dans les inserts, mises à jour et WHERE clauses et puis fournir que plus tard. Par exemple:

SELECT * FROM users WHERE username = 'bob'

vs

SELECT * FROM users WHERE username = ?

ou

SELECT * FROM users WHERE username = :username

dépend de votre plate-forme.

j'ai vu des bases de données mises à genoux en faisant ça. Fondamentalement, chaque fois qu'une base de données moderne rencontre une nouvelle requête, elle doit la compiler. S'il rencontre une requête qu'il a vu avant, vous donnez à la base de données l'occasion de mettre en cache la requête compilée et le plan d'exécution. En faisant la requête beaucoup vous donnez à la base de données l'occasion de comprendre cela et d'optimiser en conséquence (par exemple, en épinglant la requête compilée en mémoire).

en utilisant des déclarations préparées vous donnera également des statistiques significatives sur la fréquence de certaines requêtes sont utilisées.

déclarations préparées vous protégera également mieux contre les attaques par injection SQL.

9. Pas assez de normalisation

normalisation de la base de données est essentiellement le processus d'optimisation de la conception de base de données ou comment vous organisez vos données en tableaux.

Cette semaine, J'ai trouvé un code où quelqu'un avait implosé un tableau et l'avait inséré dans un seul champ dans une base de données. Normalisation qui consisterait à traiter élément de ce tableau comme une ligne dans une table d'enfant (c'est à dire un un-à-plusieurs).

cela est également apparu dans meilleure méthode pour stocker une liste d'utilisateurs IDs :

j'ai vu dans d'autres systèmes que la liste est stockée dans un tableau PHP sérialisé.

mais le manque de normalisation prend de nombreuses formes.

plus:

10. Normaliser trop

cela peut sembler comme une contradiction au point précédent mais la normalisation, comme beaucoup de choses, est un outil. C'est un moyen pour une fin et non une fin en soi. Je pense que beaucoup de développeurs l'oublient et commencent à traiter un "moyen" comme une "fin". Les tests unitaires en sont un excellent exemple.

j'ai travaillé une fois sur un système qui avait une énorme hiérarchie pour clients qui sont allés quelque chose comme:

Licensee ->  Dealer Group -> Company -> Practice -> ...

tel que vous avez dû joindre environ 11 tableaux ensemble avant de pouvoir obtenir des données significatives. C'était un bon exemple de normalisation poussée trop loin.

plus précisément, une dénormalisation soignée et réfléchie peut avoir d'énormes avantages en termes de performances, mais il faut être très prudent en faisant cela.

plus:

11. Utilisation des arcs exclusifs

un arc exclusif est une erreur courante où une table est créée avec deux ou plusieurs clés étrangères où une seule d'entre elles peut être non-null. grosse erreur. Pour une chose, il devient beaucoup plus difficile de maintenir l'intégrité des données. Après tout, même avec l'intégrité référentielle, rien n'empêche deux ou plusieurs de ces clés étrangères en cours de jeu (complexe vérifier les contraintes nonobstant).

à Partir de Guide Pratique de Conception de Base de données Relationnelle :

nous avons fortement déconseillé la construction exclusive d'arc partout possible, pour la bonne raison qu'ils peuvent être maladroit d'écrire le code et de poser plus de difficultés de maintenance.

12. Ne pas faire l'analyse des performances sur des requêtes à tous les

le pragmatisme règne en maître, en particulier dans le monde des bases de données. Si vous vous en tenez aux principes au point qu'ils sont devenus un dogme, alors vous avez probablement fait des erreurs. Prenez l'exemple des questions agrégées ci-dessus. La version agrégée peut sembler "jolie", mais sa performance est lamentable. Une comparaison des performances aurait dû mettre un terme au débat (mais ce n'est pas le cas), mais plus précisément: dangereux.

13. Dépendance excessive à L'égard de l'UNION tout particulièrement les constructions syndicales

une UNION en termes SQL concaténate simplement ensembles de données congruents, ce qui signifie qu'ils ont le même type et le nombre de colonnes. La différence entre eux est que L'UNION tout est une concaténation simple et devrait être préféré chaque fois que possible tandis qu'une UNION fera implicitement un DISTINCT pour éliminer les tuples en double.

Les syndicats, comme distincts, ont leur place. Il y a des demandes valides. Mais si vous en faites beaucoup, surtout dans les sous-séries, alors vous faites probablement quelque chose de mal. Cela pourrait être un cas de mauvaise construction de requête ou un modèle de données mal conçu vous forçant à faire de telles choses.

syndicats, en particulier lorsqu'ils sont utilisés dans les jointures ou sous-séries dépendantes, peut paralyser une base de données. Essayez de les éviter autant que possible.

14. Utilisation ou conditions dans les requêtes

Cela peut sembler inoffensif. Après tout, les And sont OK. OU devrait être OK trop à droite? Mauvais. Fondamentalement et condition restreint l'ensemble de données tandis qu'une ou condition augmente il mais pas d'une manière qui se prête à l'optimisation. En particulier lorsque les différentes conditions de la salle D'opération peuvent se croiser, obligeant ainsi l'optimiseur à effectuer efficacement une opération distincte sur le résultat.

Mauvais:

... WHERE a = 2 OR a = 5 OR a = 11

mieux:

... WHERE a IN (2, 5, 11)

maintenant votre optimiseur SQL peut transformer efficacement la première requête en la seconde. Mais il ne pourrait pas. Il suffit de ne pas le faire.

15. Ne pas concevoir leur modèle de données pour se prêter à des solutions performantes

c'est un point difficile à quantifier. Il est généralement observé par ses effet. Si vous vous trouvez à écrire des requêtes gnarly pour des tâches relativement simples ou que les requêtes pour trouver des informations relativement simples ne sont pas efficaces, alors vous avez probablement un mauvais modèle de données.

d'une certaine façon ce point résume tous les précédents, mais il est plus d'une histoire de mise en garde que faire des choses comme l'optimisation de requête est souvent fait d'abord quand il devrait être fait second. Tout d'abord, vous devez vous assurer d'avoir un bon modèle de données avant en essayant d'optimiser les performances. Comme Knuth a dit:

l'optimisation Prématurée est la racine de tout mal

16. Utilisation incorrecte de la base de données

tous les changements de données pour un procédé spécifique doivent être atomiques. I. e. Si l'opération réussit, il le fait complètement. En cas d'échec, les données restent inchangées. - Il ne devrait pas y avoir de possibilité de changements "à moitié faits".

idéalement, la façon la plus simple d'y parvenir est que la conception du système dans son ensemble devrait s'efforcer de prendre en charge toutes les modifications de données au moyen d'énoncés simples INSERT/UPDATE/DELETE. Dans ce cas, aucune opération de manipulation est nécessaire, comme votre moteur de base de données devrait le faire automatiquement.

toutefois, si l'un des processus exige que de multiples déclarations soient effectuées en tant qu'unité pour maintenir les données dans un état uniforme, le contrôle des transactions approprié est nécessaire.

  • commencer une opération avant le premier énoncé.
  • valider la Transaction après la dernière instruction.
  • en cas d'erreur, annuler la Transaction. Et très NB! N'oubliez pas de sauter/annuler toutes les déclarations qui suivent après l'erreur.

également recommandé de faire attention aux subtilités de la façon dont votre couche de connectivité de base de données, et le moteur de base de données interagir à cet égard.

17. Ne pas comprendre le paradigme "set-based "

le langage SQL suit un paradigme spécifique adapté à des types de problèmes spécifiques. En dépit de diverses extensions propres à un fournisseur, le langage a du mal à traiter des problèmes qui sont triviaux dans des langues comme Java, C#, Delphi, etc.

Ce manque de compréhension se manifeste de plusieurs façons.

  • imposer de manière inappropriée trop de logique procédurale ou impérative à la base de données.
  • utilisation inappropriée ou excessive de curseurs. Surtout quand une seule requête suffit.
  • supposant incorrectement que déclenche le feu une fois par rangée affectée dans les mises à jour à plusieurs rangées.

déterminer une répartition claire des responsabilités et s'efforcer d'utiliser l'outil approprié pour résoudre chaque problème.

1003
répondu cletus 2017-05-23 13:31:37
la source

base de données des Clés de la conception et de la programmation des erreurs commises par les développeurs

  • conception et utilisation égoïstes de la base de données. les développeurs traitent souvent la base de données comme leur magasin d'objets perso NNELS persistants sans tenir compte des besoins des autres parties prenantes dans les données. Cela s'applique également aux architectes d'application. Mauvaise conception de base de données et l'intégrité des données rend difficile pour les tiers qui travaillent avec les données et peut augmenter considérablement le cycle de vie du système des coûts. Les rapports et les erreurs ont tendance à être une mauvaise cousine dans la conception des applications et ne sont faits qu'après coup.

  • abus de données dénormalisées. outrepasser les données dénormalisées et essayer de les maintenir dans l'application est une recette pour les problèmes d'intégrité des données. Utilisez la dénormalisation avec parcimonie. Ne voulant pas ajouter une jointure à une requête n'est pas une excuse pour denormalising.

  • Peur de l'écriture SQL. SQL n'est pas une science de fusée et est en fait assez bon à faire son travail. Les couches de mappage O/R sont assez bonnes pour faire les 95% de requêtes qui sont simples et s'intègrent bien dans ce modèle. Parfois SQL est la meilleure façon de faire le travail.

  • Dogmatique "Pas de Procédures Stockées" politiques. peu importe si vous croyez stocké les procédures sont mauvaises, ce genre d'attitude dogmatique n'a pas sa place dans un projet de logiciel.

  • ne comprend pas la conception de la base de données. la Normalisation est votre ami et c'est pas la science de la fusée. L'adhésion et la cardinalité sont des concepts assez simples - si vous êtes impliqué dans le développement d'applications de base de données, il n'y a vraiment aucune excuse pour ne pas les comprendre.

110
répondu ConcernedOfTunbridgeWells 2017-05-23 14:55:02
la source
  1. N'utilisant pas le contrôle de version sur le schéma de la base de données
  2. travailler directement contre une base de données en direct
  3. ne pas lire et comprendre des concepts de base de données plus avancés (Index, index groupés, contraintes, vues matérialisées, etc.)
  4. échec au test d'extensibilité ... les données de test de seulement 3 ou 4 lignes ne vous donneront jamais l'image réelle de la performance réelle
80
répondu Rad 2009-03-07 18:33:11
la source

surutilisation et / ou dépendance aux procédures stockées.

certains développeurs d'applications voient les procédures stockées comme une extension directe du code de niveau Intermédiaire/front end. Cela semble être un trait commun chez les développeurs de stack de Microsoft (j'en suis un, mais j'en suis sorti) et produit de nombreuses procédures stockées qui exécutent la logique d'affaires complexe et le traitement des flux de travail. C'est beaucoup mieux fait ailleurs.

procédures stockées sont utiles là où il a en fait été prouvé que certains facteurs techniques réels nécessitent leur utilisation (par exemple, la performance et la sécurité) par exemple, en maintenant l'agrégation/filtrage de grands ensembles de données "proche des données".

j'ai récemment dû aider à maintenir et à améliorer une grande application de bureau Delphi dont 70% de la logique d'affaires et des règles ont été mises en œuvre dans 1400 procédures stockées de Serveur SQL (le reste dans les gestionnaires D'événements UI). C'était un cauchemar, principalement en raison de la difficulté d'introduire des tests unitaires efficaces à TSQL, manque d'encapsulation et mauvais outils (débogueurs, éditeurs).

Travailler avec une équipe Java dans le passé, j'ai vite remarqué que souvent le contraire tient dans cet environnement. Un architecte Java m'a dit un jour: "la base de données est pour les données, pas pour le code.".

ces jours-ci je pense que c'est une erreur de ne pas considérer procs stockés du tout, mais ils devraient être utilisés avec parcimonie (pas par défaut) dans des situations là où ils offrent des avantages utiles (voir les autres réponses).

46
répondu Ashley Henderson 2010-09-23 21:24:49
la source

problème numéro un? Ils ne testent que les bases de données de jouets. Donc ils n'ont aucune idée que leur SQL va ramper quand la base de données devient grande, et quelqu'un doit venir le long et le réparer plus tard (ce son que vous pouvez entendre est mes dents grincement).

41
répondu Bob Moore 2009-03-07 18:37:54
la source

N'utilisant pas d'index.

31
répondu Christophe Herreman 2009-03-07 17:19:42
la source

mauvaise Performance causée par les sous-séries corrélées

la plupart du temps, vous voulez éviter les sous-séries corrélées. Une sous-requête corrélée si, au sein de la sous-requête, il y a une référence à une colonne de la requête externe. Lorsque cela se produit, le sous-jeu est exécuté au moins une fois pour chaque ligne retournée et pourrait être exécuté plus de fois si d'autres conditions sont appliquées après que la condition contenant le sous-jeu corrélé est appliquée.

pardonnez l'exemple artificiel et la syntaxe Oracle, mais disons que vous vouliez trouver tous les employés qui ont été embauchés dans l'un de vos magasins depuis la dernière fois que le magasin a fait moins de 10 000 $de ventes en une journée.

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

la sous-requête dans cet exemple est corrélée à la requête externe par le store_id et serait exécutée pour chaque employé dans votre système. Une façon d'optimiser cette requête est de déplacer le sous-jeu vers un inline-vue.

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

dans cet exemple, la requête dans la clause from est maintenant une vue en ligne (encore une syntaxe spécifique à Oracle) et n'est exécutée qu'une seule fois. Selon votre modèle de données, cette requête s'exécutera probablement beaucoup plus rapidement. Il serait mieux que la première requête que le nombre de salariés a augmenté. La première question pourrait en fait donner de meilleurs résultats s'il y avait peu d'employés et de nombreux magasins (et peut-être beaucoup de magasins n'avaient pas d'employés) et les ventes quotidiennes. la table a été indexée sur store_id. Ce n'est pas un scénario probable, mais montre comment une requête corrélée pourrait éventuellement mieux fonctionner qu'une alternative.

j'ai vu des développeurs juniors corréler des sous-séries à plusieurs reprises et cela a généralement eu un impact sévère sur la performance. Cependant, lorsque vous supprimez un sous-jeu corrélé, assurez-vous de regarder le expliquer le plan avant et après pour vous assurer que vous ne rendez pas la performance pire.

28
répondu adam 2010-12-13 18:48:46
la source

dans mon expérience:

Ne pas communiquer avec des AD expérimentés.

21
répondu Kb. 2009-03-07 17:42:55
la source

utilisant L'accès au lieu d'une base de données "réelle". Il y a beaucoup de grandes bases de données petites et même libres comme SQL Express , MySQL , et SQLite qui fonctionneront et évolueront beaucoup mieux. Les applications doivent souvent évoluer de manière inattendue.

17
répondu Nathan Voxland 2009-03-08 07:20:43
la source

oubliant d'établir des relations entre les tables. Je me souviens avoir dû nettoyer ça quand j'ai commencé à travailler chez mon employeur actuel.

16
répondu TheTXI 2009-03-07 17:16:30
la source

utilisant Excel pour stocker (de grandes quantités de) données.

j'ai vu des entreprises tenir des milliers de lignes et en utilisant plusieurs feuilles de travail (en raison de la limite de ligne de 65535 sur les versions précédentes D'Excel).


Excel convient bien aux rapports, à la présentation des données et à d'autres tâches, mais ne devrait pas être traité comme une base de données.

14
répondu ML-- 2010-08-02 21:18:26
la source

j'aimerais ajouter: Favoriser le code "élégant" par rapport au code très performant. Le code qui fonctionne le mieux contre les bases de données est souvent laid à l'oeil du développeur d'application.

croyant cette absurdité sur l'optimisation prématurée. Les bases de données doivent tenir compte du rendement de la conception originale et de tout développement subséquent. La Performance est de 50% de la conception de la base de données (40% est l'intégrité des données et les 10% restants sont la sécurité) à mon avis. Les bases de données qui ne sont pas construites à partir bottom up à effectuer donnera de mauvais résultats une fois que les utilisateurs réels et le trafic réel sont placés contre la base de données. L'optimisation prématurée ne veut pas dire pas d'optimisation! Cela ne signifie pas que vous devez écrire du code qui sera presque toujours mal fonctionner parce que vous le trouvez plus facile (curseurs par exemple qui ne devrait jamais être autorisé dans une base de données de production à moins que tout le reste a échoué). Cela signifie que vous n'avez pas besoin de chercher à évincer ce dernier peu de performance jusqu'à ce que vous avez besoin. Beaucoup de choses sont connues sera plus efficace sur les bases de données, de ne pas en tenir compte dans la conception et le développement est myope au mieux.

14
répondu HLGEM 2010-09-23 21:28:20
la source

N'utilisant pas de requêtes paramétrées. Ils sont assez pratiques pour arrêter Injection SQL .

il s'agit d'un exemple précis de non-élimination des données d'entrée, mentionné dans une autre réponse.

13
répondu Ash 2009-03-07 19:52:46
la source

je déteste quand les développeurs utilisent des instructions de sélection emboîtées ou même des fonctions le retour le résultat d'une instruction de sélection à l'intérieur de la partie" SELECT " d'une requête.

je suis en fait surpris que je ne vois pas cela ailleurs ici, peut-être que je l'ai négligé, bien que @adam ait un problème similaire indiqué.

exemple:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

dans ce scénario, si MyTable renvoie 10000 lignes le résultat est comme si la requête venait de s'exécuter 20001 requêtes, car il a dû exécuter la requête initiale Plus requête chacune des autres tables une fois pour chaque ligne de résultat.

développeurs peuvent s'en tirer avec ce travail dans un environnement de développement où ils ne renvoient que quelques lignes de données et les sous-tableaux ont généralement une petite quantité de données, mais dans un environnement de production, ce type de requête peut devenir exponentiellement coûteux que plus de données est ajouté aux tableaux.

un meilleur (pas nécessairement parfait) serait quelque chose comme:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

cela permet aux optimiseurs de base de données de mélanger les données, plutôt que requery sur chaque enregistrement de la table principale et je trouve généralement quand je dois corriger le code où ce problème a été créé, je finis généralement par augmenter la vitesse des requêtes de 100% ou plus tout en réduisant simultanément L'utilisation CPU et mémoire.

12
répondu CStroliaDavis 2011-02-23 19:25:31
la source

pour les bases de données basées sur SQL:

  1. ne pas tirer avantage des indices groupés ou ne pas choisir la ou les mauvaises colonnes pour grouper.
  2. N'utilisant pas un type de données série (autonumber) comme clé primaire pour joindre une clé étrangère (INT) dans une relation de table parent/enfant.
  3. ne pas mettre à jour les statistiques sur une table lorsque de nombreux enregistrements ont été insérés ou supprimés.
  4. ne pas réorganiser (c.-à-d. décharger, laisser tomber), recréer, charger et réindexer des tableaux) lorsque plusieurs lignes ont été insérées ou supprimées (certains moteurs conservent physiquement les lignes supprimées dans un tableau avec un indicateur de suppression).)
  5. ne pas profiter de FRAGMENT sur L'EXPRESSION (si pris en charge) sur les grandes tables qui ont des taux de transaction élevés.
  6. Choisir le mauvais type de données pour une colonne!
  7. ne pas choisir un nom de colonne approprié.
  8. N'ajoutant pas de nouvelles colonnes à la fin de table.
  9. ne pas créer les index appropriés pour supporter les requêtes fréquemment utilisées.
  10. création d'index sur des colonnes avec peu de valeurs possibles et création d'index inutiles.

    ...de plus à ajouter.
12
répondu Frank Computer 2011-06-14 06:00:21
la source
  • ne pas prendre de sauvegarde avant de corriger un problème dans la base de données de production.

  • utilisant des commandes DDL sur des objets stockés(comme des tables, des vues) dans les procédures stockées.

  • peur d'utiliser proc stocké ou peur d'utiliser des requêtes ORM lorsque celui-ci est plus efficace/approprié à utiliser.

  • en Ignorant l'utilisation d'une base de données, profileur de, qui peut vous dire exactement ce que votre requête ORM est converti en fin de Compte et donc vérifier la logique ou même pour le débogage quand vous n'utilisez pas ORM.

9
répondu WhoIsNinja 2011-01-24 21:37:52
la source

ne Pas faire à un niveau correct normalisation . Vous voulez vous assurer que les données ne sont pas dupliquées, et que vous divisez des données dans différentes selon le besoin. Vous devez également vous assurer que vous ne suivez pas la normalisation trop autant que cela nuira à la performance.

8
répondu Nathan Voxland 2009-03-07 17:22:35
la source

le Traitement de la base de données comme un simple mécanisme de stockage (soit glorifié collections de la bibliothèque), et donc subordonné à leur application (ignorer les autres applications qui partagent les données)

8
répondu finnw 2009-03-07 19:02:56
la source
  • rejeter un ORM comme Hibernate de main, pour des raisons comme "c'est trop magique" ou "pas sur mon base de données".
  • S'en remettre trop lourdement à un ORM comme Hibernate et essayer de le dénicher là où ce n'est pas approprié.
8
répondu Adam Jaskiewicz 2009-04-02 22:33:48
la source

1 - utiliser inutilement une fonction sur une valeur dans une clause where avec le résultat de cet index non utilisé.

exemple:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

au lieu de

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

et dans une moindre mesure: ne pas ajouter d'indices fonctionnels aux valeurs qui en ont besoin...

2 - ne pas ajouter de contraintes de vérification pour assurer la validité des données. Les contraintes peuvent être utilisées par l'optimiseur de requêtes, et elles aident vraiment à s'assurer que vous pouvez faire confiance à vos invariants. Il n'y a aucune raison de ne pas les utiliser.

3 - ajouter des colonnes non normalisées aux tables à partir de la paresse pure ou de la pression de temps. Les choses ne sont généralement pas conçues de cette façon, mais évoluent en cela. Le résultat final, sans faute, est une tonne de travail à essayer de nettoyer le gâchis lorsque vous êtes mordu par l'intégrité des données perdues dans les évolutions futures.

pensez à ceci, une table sans données est très bon marché à redessiner. Une table avec quelques millions de disques sans intégrité... pas si bon marché à la refonte. Ainsi, faire la conception correcte lors de la création de la colonne ou du tableau est amorti en bêches.

4 - pas tellement sur la base de données en soi, mais en effet ennuyeux. Ne se souciant pas de la qualité du code de SQL. Le fait que votre SQL soit exprimé en texte ne le rend pas OK pour se cacher la logique dans les tas d'algorithmes de manipulation de chaîne. Il est parfaitement possible d'écrire SQL dans un texte d'une manière qui est effectivement lisible par votre collègue programmeur.

8
répondu John Nilsson 2010-10-04 15:05:17
la source

cela a déjà été dit, mais: indexes, indexes, indexes . J'ai vu tellement de cas d'applications web d'entreprise peu performantes qui ont été corrigées en faisant simplement un peu de profilage (pour voir quelles tables étaient frappées beaucoup), puis en ajoutant un index sur ces tables. Cela ne nécessite même pas beaucoup de connaissances en écriture SQL, et le gain est énorme.

éviter la duplication de données comme la peste. Certaines personnes préconisent un peu la duplication ne fera pas de mal et améliorera la performance. Hey, Je ne dis pas que tu dois torturer ton schéma en troisième forme normale, jusqu'à ce qu'il soit si abstrait que même les DBA ne savent pas ce qui se passe. Il suffit de comprendre que chaque fois que vous dupliquez un ensemble de noms, ou des codes zip, ou des codes d'expédition, les copies tomberont hors de la synchronisation avec l'autre éventuellement. Il VA se passer. Et vous vous en prendrez à vous-même quand vous exécuterez le script de maintenance hebdomadaire.

et enfin: utilisation une convention de nommage claire, cohérente et intuitive. De la même manière qu'un morceau de code bien écrit doit être lisible, un bon schéma ou une requête SQL doit être lisible et pratiquement dire vous ce qu'il fait, même sans commentaires. Vous vous remercierez dans six mois, quand vous aurez à maintenir les tables. "SELECT account_number, billing_date FROM national_accounts" est infiniment plus facile à utiliser que"SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".

7
répondu pbailey19 2009-07-29 00:23:27
la source

N'exécute pas une requête SELECT correspondante avant D'exécuter la requête DELETE (en particulier sur les bases de données de production)!

6
répondu Jamol 2010-01-06 15:11:37
la source

l'erreur la plus fréquente que j'ai vu en vingt ans: ne pas planifier à l'avance. De nombreux développeurs vont créer une base de données et des tables, puis Modifier et étendre continuellement les tables au fur et à mesure qu'ils construisent les applications. Le résultat final est souvent un gâchis et inefficaces et difficiles à nettoyer ou de simplifier plus tard.

5
répondu Skatterbrainz 2011-01-29 06:56:14
la source

a) valeurs de requête Hardcoding dans la chaîne de caractères

B) placer le code d'interrogation de la base de données dans l'action "OnButtonPress" dans une application Windows Forms

j'ai vu les deux.

4
répondu Benoit 2010-09-23 21:29:57
la source

ne pas accorder assez d'attention à la gestion des connexions de base de données dans votre application. Ensuite, vous découvrez l'application, l'ordinateur, le serveur et le réseau est bouché.

4
répondu chefsmart 2010-09-23 21:32:34
la source
  1. " penser qu'ils sont des AD et des modélisateurs/concepteurs de données quand ils n'ont aucun endoctrinement formel d'aucune sorte dans ces domaines.

  2. pensant que leur projet ne nécessite pas de DBA parce que tout cela est facile/trivial.

  3. l'incapacité à discerner entre le travail qui doit être fait dans la base de données, et le travail qui doit être fait dans l'application.

  4. ne pas valider les sauvegardes ou ne pas sauvegarder.

  5. intégrant le SQL brut dans leur code.

4
répondu jonesy 2011-01-05 16:55:11
la source

voici un lien vers la vidéo appelée Classic Database Development Mistakes and five ways to overcome them 'by Scott Walz

3
répondu Charles Faiga 2009-03-07 20:07:29
la source

ne pas avoir une compréhension du modèle de concurrence des bases de données et de la façon dont cela affecte le développement. Il est facile d'ajouter des index et de modifier les requêtes après coup. Toutefois, les applications conçues sans considération appropriée pour les points chauds, l'assertion de ressources et du bon fonctionnement (en Supposant que ce que vous venez de lire est toujours valide!) peut nécessiter des modifications importantes au niveau de la base de données et de l'application pour être corrigées ultérieurement.

3
répondu Einstein 2010-09-23 21:33:10
la source

ne comprend pas comment un SGBD fonctionne sous le capot.

Vous ne pouvez pas conduire correctement un bâton, sans comprendre comment un embrayage fonctionne. Et vous ne pouvez pas comprendre comment utiliser une Base de données, sans comprendre que vous êtes vraiment en train d'écrire un fichier sur votre disque dur.

spécifiquement:

  1. savez-vous ce qu'est un indice en grappes? As-tu pensé à ça quand tu conçu votre schéma?

  2. savez-vous comment utiliser correctement les index? Comment réutiliser un indice? Savez-vous ce qu'est un indice de couverture?

  3. si grand, vous avez des index. Quelle est la taille d'une rangée dans votre index? Quelles sont les dimensions de l'index lorsque vous avez beaucoup de données? Volonté qui s'intègrent facilement dans la mémoire? S'il n'est pas inutile comme un indice.

  4. Avez-vous déjà utilisé Expliquer en MySQL? Grand. Maintenant, être honnête avec soi-même: Avez-vous compris même la moitié de ce que vous avez vu? Non, vous n'avez probablement pas. Correctif.

  5. comprenez-vous le Cache de requête? Savez-vous ce qui rend une requête inaccessible?

  6. utilisez-vous MyISAM? Si vous avez besoin d'une recherche en texte intégral, Myisam's est nul de toute façon. L'Utilisation De Sphinx. Puis passez à Inno.

3
répondu Shane H 2010-12-13 18:42:34
la source
  1. à l'Aide d'un ORM pour faire des mises à jour en vrac
  2. sélectionnant plus de données que nécessaire. Encore une fois, généralement fait lors de l'utilisation d'un ORM
  3. sqls de tir en boucle.
  4. ne disposant pas de bonnes données d'essai et ne remarquant une dégradation de la performance que sur des données vivantes.
3
répondu Sriram 2010-12-13 20:36:29
la source

Autres questions sur database database-design