Que doit savoir chaque développeur sur les bases de données? [fermé]


206

Que cela nous plaise ou non, de nombreux développeurs, sinon la plupart d'entre nous, travaillent régulièrement avec des bases de données ou peuvent en avoir un jour. Et compte tenu de la quantité d'abus et d'abus dans la nature, et du volume de questions liées à la base de données qui se posent chaque jour, il est juste de dire qu'il existe certains concepts que les développeurs devraient connaître - même s'ils ne conçoivent pas ou ne travaillent pas avec bases de données aujourd'hui. Alors:



Quels sont les concepts importants que les développeurs et autres professionnels du logiciel devraient connaître sur les bases de données?


Lignes directrices pour les réponses:


Gardez votre liste courte.
Un concept par réponse est préférable.

Soyez précis .
La «modélisation des données» peut être une compétence importante , mais qu'est-ce que cela signifie précisément?

Expliquez votre justification.
Pourquoi votre concept est-il important? Ne vous contentez pas de dire «utiliser des index». Ne tombez pas dans les «meilleures pratiques». Convainquez votre public d'aller en savoir plus.

Upvote réponses avec lesquelles vous êtes d'accord.
Lisez d'abord les réponses des autres. Une réponse de haut rang est une déclaration plus efficace que deux réponses de bas rang. Si vous avez plus à ajouter, ajoutez un commentaire ou référencez l'original.

Ne sous-estimez pas quelque chose simplement parce qu'il ne s'applique pas à vous personnellement.
Nous travaillons tous dans des domaines différents. L'objectif ici est de fournir une orientation aux novices de bases de données pour acquérir une compréhension bien fondée et complète de la conception et du développement de bases de données, et non de concourir pour le titre de plus important.


15
Pourquoi voter pour fermer ça ?? C'est un Wikia communautaire et donc approprié.
David

5
Je voterai pour rouvrir s'il est fermé ... J'aimerais également voir une liste de ces choses que les administrateurs de base de données devraient (mais ne savent pas) sur la POO et la conception de logiciels d'application / systèmes.
Charles Bretana

7
@gnovice: Le mot "subjectif" dans ce contexte fait référence à des questions qui sont entièrement une question d'opinion. "Que pensez-vous du livre de Joe Celko?" - c'est une question subjective. Cette question sollicite des informations objectives, il se trouve qu'il n'y a pas de "bonne" réponse unique. Je pense qu'il est important de prendre du recul et de demander: "Est-ce juste une plaisanterie oiseuse, ou est-ce utile pour certains développeurs?" Mes deux cents de toute façon - ce n'est pas comme si je gagnais des points de représentant pour cela. :-)
Aaronaught

6
Personnellement, je déteste ces questions. Ils équivalent presque toujours à des tas d'opinions personnelles, à la lumière d'informations utilisables et à des déclarations subjectives. Mais je ne suis pas prêt à le fermer pour cette seule raison; cela pourrait être à mi-chemin décent, Aaron, si vous définissez des lignes directrices pour les réponses: réponses à un seul sujet (que devez-vous savoir et pourquoi devriez-vous le savoir), pas de doublons, vote positif avec lequel vous êtes d'accord ... et la plupart surtout, transformez vos propres opinions en réponses qui le démontrent. Dans l'état actuel des choses, cela se lit comme un article de blog ou une discussion sur un forum, qui n'ont aucun intérêt pour SO.
Shog9

4
Je trouve cela plutôt intéressant: "C'est un wiki communautaire et donc approprié." Comment diable un CW peut-il le rendre approprié? Soit une question est appropriée ou non, et je pense que cette question est ainsi subjectifs pour être utile si quelqu'un est à la recherche d'une réponse. Cela peut être intéressant, mais ce n'est pas la seule caractéristique qu'une question doit avoir.
Georg Schölly

Réponses:


106

La toute première chose que les développeurs devraient savoir sur les bases de données est la suivante: à quoi servent les bases de données ? Pas comment fonctionnent-ils, ni comment en créer un, ni même comment écrire du code pour récupérer ou mettre à jour les données dans une base de données. Mais à quoi servent-ils?

Malheureusement, la réponse à celle-ci est une cible mouvante. Dans le domaine des bases de données, des années 1970 au début des années 1990, les bases de données étaient destinées au partage de données. Si vous utilisiez une base de données et que vous ne partagiez pas de données, vous étiez soit impliqué dans un projet académique, soit vous gaspilliez des ressources, y compris vous-même. Mettre en place une base de données et apprivoiser un SGBD étaient des tâches si monumentales que le retour sur investissement, en termes de données exploitées plusieurs fois, devait être énorme pour correspondre à l'investissement.

Au cours des 15 dernières années, les bases de données sont devenues utilisées pour stocker les données persistantes associées à une seule application. La création d'une base de données pour MySQL , ou Access , ou SQL Server est devenue si routinière que les bases de données sont devenues presque une partie courante d'une application ordinaire. Parfois, cette mission limitée initiale est poussée vers le haut par le fluage de la mission, à mesure que la valeur réelle des données devient apparente. Malheureusement, les bases de données conçues avec un seul objectif en tête échouent souvent de façon spectaculaire lorsqu'elles commencent à être placées dans un rôle à l'échelle de l'entreprise et essentiel à la mission.

La deuxième chose que les développeurs doivent apprendre sur les bases de données est la vision du monde centrée sur les données . La vision du monde centrée sur les données est plus différente de la vision du monde centrée sur les processus que tout ce que la plupart des développeurs ont jamais appris. Comparé à cet écart, l'écart entre la programmation structurée et la programmation orientée objet est relativement faible.

La troisième chose que les développeurs doivent apprendre, au moins dans une vue d'ensemble, est la modélisation des données, y compris la modélisation des données conceptuelles, la modélisation des données logiques et la modélisation des données physiques.

La modélisation conceptuelle des données est vraiment une analyse des exigences d'un point de vue centré sur les données.

La modélisation logique des données est généralement l'application d'un modèle de données spécifique aux exigences découvertes dans la modélisation conceptuelle des données. Le modèle relationnel est beaucoup plus utilisé que tout autre modèle spécifique, et les développeurs doivent apprendre le modèle relationnel à coup sûr. Concevoir un modèle relationnel puissant et pertinent pour une exigence non triviale n'est pas une tâche triviale. Vous ne pouvez pas créer de bonnes tables SQL si vous comprenez mal le modèle relationnel.

La modélisation des données physiques est généralement spécifique au SGBD et n'a pas besoin d'être apprise en détail, sauf si le développeur est également le constructeur de la base de données ou le DBA. Ce que les développeurs doivent comprendre, c'est dans quelle mesure la conception de la base de données physique peut être séparée de la conception de la base de données logique, et dans quelle mesure la production d'une base de données à grande vitesse peut être accomplie simplement en peaufinant la conception physique.

La prochaine chose que les développeurs doivent apprendre est que, bien que la vitesse (performances) soit importante, d'autres mesures de la qualité de la conception sont encore plus importantes , telles que la possibilité de réviser et d'étendre la portée de la base de données sur la route, ou la simplicité de la programmation.

Enfin, toute personne qui dérange les bases de données doit comprendre que la valeur des données survit souvent au système qui les a capturées .

Ouf!


Très bien écrit! Et la perspective historique est idéale pour les personnes qui ne faisaient pas de travail de base de données à ce moment-là (c'est-à-dire moi).
Aaronaught

6
Joliment écrit. Et je pense que votre dernier point est trop souvent ignoré par les gens qui essaient de «le faire».
DaveE

1
Il y a un lien entre ce que j'ai écrit et des sujets tels que Explain Plan, Indexing et Data Normalization. J'adorerais discuter de cette connexion plus en profondeur dans une sorte de forum de discussion. SO n'est pas un tel forum.
Walter Mitty

1
Si vous avez trouvé la lecture de ce monstre à la vapeur, imaginez ce que c'était que de l'écrire! Je n'avais pas l'intention d'écrire un essai. Une fois que j'ai commencé, ça a semblé couler. Celui qui a ajouté le caractère gras a vraiment aidé les lecteurs, l'OMI.
Walter Mitty

3
@Walter Vous avez fourni des explications pour tous vos points à l'exception de celui-ci: "La deuxième chose que les développeurs doivent apprendre sur les bases de données est la vue du monde centrée sur les données. La vue du monde centrée sur les données est plus différente de la vue du monde centrée sur les processus que tout ce que la plupart des développeurs ont appris. Par rapport à cet écart, l'écart entre la programmation structurée et la programmation orientée objet est relativement faible. " Pourriez-vous développer cela? Vous avez déclaré que l'écart était important, mais je suppose que j'aimerais vraiment comprendre la vue centrée sur les données et la façon dont elle est découplée de la vue du processus.
jedd.ahyoung

73

Bonne question. Voici quelques réflexions sans ordre particulier:

  1. La normalisation, au moins jusqu'à la deuxième forme normale, est essentielle.

  2. L'intégrité référentielle est également essentielle, avec des considérations appropriées de suppression et de mise à jour en cascade.

  3. Bonne et bonne utilisation des contraintes de contrôle. Laissez la base de données faire autant de travail que possible.

  4. Ne dispersez pas la logique métier dans la base de données et le code de niveau intermédiaire. Choisissez l'un ou l'autre, de préférence dans le code de niveau intermédiaire.

  5. Décidez d'une approche cohérente pour les clés primaires et les clés en cluster.

  6. Ne pas trop indexer. Choisissez judicieusement vos index.

  7. Désignation cohérente des tables et des colonnes. Choisissez un standard et respectez-le.

  8. Limitez le nombre de colonnes de la base de données qui accepteront des valeurs nulles.

  9. Ne vous laissez pas emporter par les déclencheurs. Ils ont leur utilité mais peuvent compliquer les choses à la hâte.

  10. Soyez prudent avec les FDU. Ils sont excellents mais peuvent entraîner des problèmes de performances lorsque vous ne savez pas à quelle fréquence ils peuvent être appelés dans une requête.

  11. Obtenez le livre de Celko sur la conception de bases de données. L'homme est arrogant mais connaît son affaire.


1
attention à développer le point 4. C'est un sujet qui m'a toujours intrigué.
Brad

9
@David: J'ai toujours préféré le mettre aux deux endroits. De cette façon, vous êtes protégé contre les bugs et les erreurs des utilisateurs. Il n'y a aucune raison de rendre chaque colonne nullable, ou d'autoriser l'insertion de valeurs en dehors de la plage 1-12 dans une Monthcolonne. Les règles commerciales complexes sont, bien sûr, une autre histoire.
Aaronaught

1
@Brad - La plupart de nos applications au travail ont été réalisées bien avant la mise en place de processus de programmation solides. Par conséquent, nous avons une logique métier dispersée partout. Certains sont dans l'interface utilisateur, certains dans le niveau intermédiaire et certains dans la base de données. C'est le bordel. OMI, la logique métier appartient au niveau intermédiaire.
Randy Minder

2
@David - S'il est absolument certain que les modifications de base de données ne se produiront que dans les applications, vous avez peut-être raison. Cependant, c'est probablement assez rare. Étant donné que les utilisateurs entreront probablement des données directement dans la base de données, il est recommandé de mettre également la validation dans la base de données. En outre, certains types de validation sont tout simplement plus efficacement effectués dans la base de données.
Randy Minder

1
Le point # 8 est en effet important. Comment obtenir les bons types de colonnes en général, est une chose très importante à savoir.
Chris Vest

22

Tout d'abord, les développeurs doivent comprendre qu'il y a quelque chose à savoir sur les bases de données. Ce ne sont pas seulement des dispositifs magiques où vous mettez dans le SQL et sortez des jeux de résultats, mais plutôt des logiciels très compliqués avec leur propre logique et bizarreries.

Deuxièmement, il existe différentes configurations de base de données à des fins différentes. Vous ne voulez pas qu'un développeur fasse des rapports historiques à partir d'une base de données transactionnelle en ligne s'il y a un entrepôt de données disponible.

Troisièmement, les développeurs doivent comprendre le SQL de base, y compris les jointures.

Après cela, cela dépend de la façon dont les développeurs sont impliqués. J'ai travaillé dans des emplois où j'étais développeur et DBA de facto, où les DBA étaient juste en bas de l'allée, et où les DBA sont désactivés dans leur propre région. (Je n'aime pas le troisième.) En supposant que les développeurs sont impliqués dans la conception de la base de données:

Ils doivent comprendre la normalisation de base, au moins les trois premières formes normales. Au-delà de cela, obtenez un DBA. Pour ceux qui ont une expérience avec les salles d'audience américaines (et les émissions de télévision aléatoires comptent ici), il y a le mnémonique "Dépendre de la clé, de la clé entière et rien que de la clé, alors aidez-vous Codd."

Ils doivent avoir une idée des index, ce qui signifie que je devrais avoir une idée des index dont ils ont besoin et de la manière dont ils sont susceptibles d'affecter les performances. Cela signifie ne pas avoir d'index inutiles, mais ne pas avoir peur de les ajouter pour aider les requêtes. Tout autre élément (comme le solde) doit être laissé au DBA.

Ils doivent comprendre le besoin d'intégrité des données et pouvoir indiquer où ils vérifient les données et ce qu'ils font en cas de problème. Cela ne doit pas être dans la base de données (où il sera difficile d'émettre un message d'erreur significatif pour l'utilisateur), mais doit être quelque part.

Ils devraient avoir les connaissances de base pour savoir comment obtenir un plan et comment le lire en général (au moins assez pour dire si les algorithmes sont efficaces ou non).

Ils devraient savoir vaguement ce qu'est un déclencheur, ce qu'est une vue et qu'il est possible de partitionner des morceaux de bases de données. Ils n'ont besoin d'aucune sorte de détails, mais ils ont besoin de savoir pour demander au DBA de ces choses.

Ils devraient bien sûr savoir ne pas se mêler des données de production, ou du code de production, ou quelque chose comme ça, et ils devraient savoir que tout le code source va dans un VCS.

J'ai sans doute oublié quelque chose, mais le développeur moyen n'a pas besoin d'être un DBA, à condition qu'il y ait un vrai DBA à portée de main.


19

Indexation de base

Je suis toujours choqué de voir une table ou une base de données entière sans index, ou index arbitraires / inutiles. Même si vous ne concevez pas la base de données et que vous n'avez qu'à écrire quelques requêtes, il est toujours essentiel de comprendre, au minimum:

  • Ce qui est indexé dans votre base de données et ce qui ne l'est pas:
  • La différence entre les types d'analyses, la façon dont ils sont choisis et la façon dont la façon dont vous écrivez une requête peut influencer ce choix;
  • Le concept de couverture (pourquoi vous ne devriez pas simplement écrire SELECT *);
  • La différence entre un index cluster et non cluster;
  • Pourquoi des indices plus / plus grands ne sont pas nécessairement meilleurs;
  • Pourquoi devriez-vous essayer d'éviter d'encapsuler les colonnes de filtre dans les fonctions.

Les concepteurs doivent également être conscients des anti-modèles d'index courants, par exemple:

  • L'anti-modèle Access (indexation de chaque colonne, une par une)
  • L'anti-pattern Catch-All (un index massif sur toutes ou la plupart des colonnes, apparemment créé sous l'impression erronée qu'il accélérerait toutes les requêtes imaginables impliquant l'une de ces colonnes).

La qualité de l'indexation d'une base de données - et si vous en tirez profit ou non avec les requêtes que vous écrivez - représente de loin le bloc de performances le plus important. 9 questions sur 10 publiées sur SO et d'autres forums se plaignant de mauvaises performances se révèlent invariablement dues à une mauvaise indexation ou à une expression non discutable.


Pouvez-vous élaborer sur la "couverture"? Je peux voir pourquoi SELECT * n'est pas une bonne habitude à prendre, mais je ne connais pas le sens de «couverture» et je me demande si cela fait allusion à une autre raison d'éviter SELECT *.
Edmund

1
@Edmund: un index couvre une requête si tous les champs de sortie font partie de l'index (sous forme de colonnes indexées ou de INCLUDEcolonnes dans SQL Server). Si le seul index disponible pour une requête donnée n'est pas couvrant, alors toutes les lignes doivent être récupérées, une par une, ce qui est une opération très lente, et la plupart du temps, l'optimiseur de requête décidera qu'il ne l'est pas. ne vaut pas la peine et effectuez une analyse complète de l'index / de la table à la place. C'est pourquoi vous n'écrivez pas SELECT *- cela garantit pratiquement qu'aucun index ne couvrira la requête.
Aaronaught

Merci! Cependant, en tant qu'utilisateur PostgreSQL, je n'ai pas besoin de m'inquiéter de telles choses (encore?): Les index ne contiennent pas d'informations de visibilité, donc les tuples de table doivent toujours être analysés également. En général, cependant, cela ressemble à un facteur assez important.
Edmund

@Edmund: PostgreSQL peut ne pas avoir de INCLUDEcolonnes (je ne peux pas le dire avec certitude), mais cela ne signifie pas que vous ne pouvez pas mettre les colonnes que vous souhaitez couvrir dans les données d'index réelles. C'est ce que nous avons dû faire à l'époque de SQL Server 2000. La couverture compte toujours, quel que soit le SGBD sur lequel vous vous trouvez.
Aaronaught

16

Normalisation

Cela me déprime toujours de voir quelqu'un avoir du mal à écrire une requête excessivement compliquée qui aurait été complètement simple avec un design normalisé ("Montrez-moi les ventes totales par région.").

Si vous comprenez cela au départ et que vous concevez en conséquence, vous vous épargnerez beaucoup de douleur plus tard. Il est facile de dénormaliser les performances après avoir normalisé; il n'est pas si facile de normaliser une base de données qui n'a pas été conçue de cette façon depuis le début.

À tout le moins, vous devez savoir ce qu'est le 3NF et comment y arriver. Avec la plupart des bases de données transactionnelles, il s'agit d'un très bon équilibre entre rendre les requêtes faciles à écrire et maintenir de bonnes performances.


14

Fonctionnement des index

Ce n'est probablement pas le plus important, mais c'est certainement le sujet le plus sous-estimé.

Le problème de l'indexation est que les didacticiels SQL ne les mentionnent généralement pas du tout et que tous les exemples de jouets fonctionnent sans index.

Même les développeurs plus expérimentés peuvent écrire du SQL assez bon (et complexe) sans en savoir plus sur les index que " Un index rend la requête rapide ".

En effet, les bases de données SQL font un très bon travail en tant que boîte noire:

Dites-moi ce dont vous avez besoin (donnez-moi SQL), je m'en occupe.

Et cela fonctionne parfaitement pour récupérer les résultats corrects. L'auteur du SQL n'a pas besoin de savoir ce que le système fait dans les coulisses - jusqu'à ce que tout devienne si lent .....

C'est alors que l'indexation devient un sujet. Mais c'est généralement très tard et quelqu'un (une entreprise?) Souffre déjà d'un vrai problème.

C'est pourquoi je pense que l'indexation est le sujet n ° 1 à ne pas oublier lorsque l'on travaille avec des bases de données . Malheureusement, il est très facile de l'oublier.

Avertissement

Les arguments sont empruntés à la préface de mon livre électronique gratuit " Use The Index, Luke ". Je passe beaucoup de temps à expliquer comment fonctionnent les index et comment les utiliser correctement.


12

Je veux juste souligner une observation - c'est qu'il semble que la majorité des réponses supposent que la base de données est interchangeable avec les bases de données relationnelles. Il existe également des bases de données d'objets, des bases de données de fichiers plats. Il est important d'évaluer les besoins du projet logiciel en cours. Du point de vue du programmeur, la décision concernant la base de données peut être retardée à plus tard. La modélisation des données, d'autre part, peut être réalisée très tôt et conduire à beaucoup de succès.

Je pense que la modélisation des données est un élément clé et est un concept relativement ancien, mais c'est celui qui a été oublié par beaucoup dans l'industrie du logiciel. La modélisation des données, en particulier la modélisation conceptuelle, peut révéler le comportement fonctionnel d'un système et peut être utilisée comme feuille de route pour le développement.

D'un autre côté, le type de base de données requis peut être déterminé en fonction de nombreux facteurs différents pour inclure l'environnement, le volume utilisateur et le matériel local disponible tel que l'espace disque dur.


Voulez-vous dire comme faire des diagrammes entité-relation?
crosenblum

Oui ... ai-je oublié de mentionner les ERD? :-)
FernandoZ

+1 ... Mais vous devez réaliser que vous êtes sur SO: la maison des plombiers qui passent leurs journées à corriger le décalage d'impédance ORM afin que tout ce qu'ils savent, mangent et pensent ne soit pas seulement relationnel mais "SQL" :)
SyntaxT3rr0r


9

Chaque développeur doit savoir que c'est faux: "Le profilage d'une opération de base de données est complètement différent du code de profilage."

Il y a un Big-O clair au sens traditionnel. Lorsque vous faites un EXPLAIN PLAN(ou l'équivalent), vous voyez l'algorithme. Certains algorithmes impliquent des boucles imbriquées et sont O ( n ^ 2). D'autres algorithmes impliquent des recherches d'arborescence B et sont O ( n log n ).

C'est très, très grave. Il est essentiel de comprendre pourquoi les index sont importants. Il est essentiel pour comprendre les compromis vitesse-normalisation-dénormalisation. Il est essentiel de comprendre pourquoi un entrepôt de données utilise un schéma en étoile qui n'est pas normalisé pour les mises à jour transactionnelles.

Si vous n'êtes pas sûr de l'algorithme utilisé, procédez comme suit. Arrêtez. Expliquez le plan d'exécution des requêtes. Ajustez les index en conséquence.

En outre, le corollaire: plus d'index ne sont pas meilleurs.

Parfois, un index axé sur une opération ralentit d'autres opérations. Selon le rapport des deux opérations, l'ajout d'un indice peut avoir de bons effets, aucun impact global ou être préjudiciable aux performances globales.


J'avais le sentiment que ce serait mal pris. Ce que je voulais dire par «traditionnel», c'est que vous n'avez pas vraiment de contrôle sur les algorithmes, seulement la capacité d'influencer ceux qui sont utilisés. Quoi qu'il en soit, j'ai supprimé cette langue car je ne veux rien de trop controversé dans le post principal.
Aaronaught

@ Aaron: Vous n'avez le contrôle sur les algorithmes. C'est à cela que servent les index.
S.Lott

Hmm, vous pouvez donc changer le type d'algorithme de tri utilisé par le DE? Quelles structures de données sont utilisées pour l'index? Je préférerais ne pas discuter sur ce point, c'est pourquoi je l'ai retiré, mais je maintiens l'idée de base que vous avez beaucoup moins de contrôle lorsque vous travaillez avec une base de données par rapport au code.
Aaronaught

@Aaron: Moins de contrôle ne supprime pas l'obligation de réellement comprendre si la requête est * O ** (* n ^ 2) ou * O ** (* n log n ) ou seulement ** O ** (n). Moins de contrôle ne supprime pas l'obligation de comprendre réellement ce qui se passe et de savoir comment le contrôler.
S.Lott

@ S.Lott: Je pense que nous sommes du même côté ici, car je suggérais une plus grande charge de profilage pour les bases de données - "Vous devez savoir ... [comment] lire un plan de requête". Mais mon montage semble avoir été annulé, alors ... je suppose qu'il appartient à la communauté maintenant.
Aaronaught

8

Je pense que chaque développeur doit comprendre que les bases de données nécessitent un paradigme différent .

Lors de l'écriture d'une requête pour accéder à vos données, une approche basée sur un ensemble est nécessaire. Beaucoup de gens avec une expérience interactive luttent contre cela. Et pourtant, quand ils l'adoptent, ils peuvent obtenir de bien meilleurs résultats, même si la solution n'est peut-être pas celle qui s'est présentée pour la première fois dans leur esprit itératif.


Veuillez clarifier ce que l'on entend par approche "basée sur les ensembles"
Vivian River

1
Que vous devez considérer les données comme étant dans des ensembles et considérer vos problèmes comme potentiellement résolus par l'arithmétique des ensembles - impliquant des fonctions de classement si nécessaire, des sous-requêtes, des agrégats, etc. De nombreux développeurs réfléchissent à ce qui doit être fait pour chaque ligne, ce qui est une réflexion itérative.
Rob Farley

8

Excellente question. Voyons, tout d'abord, personne ne devrait envisager d'interroger une base de données qui ne comprend pas bien les jointures. C'est comme conduire une voiture sans savoir où se trouvent le volant et les freins. Vous devez également connaître les types de données et savoir comment choisir le meilleur.

Une autre chose que les développeurs doivent comprendre est qu'il y a trois choses à garder à l'esprit lors de la conception d'une base de données:

  1. Intégrité des données - si les données ne peuvent pas être utilisées, vous n'avez essentiellement pas de données - cela signifie de ne pas mettre la logique requise dans l'application car de nombreuses autres sources peuvent toucher la base de données. Des contraintes, des clés étrangères et parfois des déclencheurs sont nécessaires à l'intégrité des données. Ne manquez pas de les utiliser parce que vous ne les aimez pas ou ne voulez pas vous embêter à les comprendre.

  2. Performances - il est très difficile de refactoriser une base de données peu performante et les performances doivent être prises en compte dès le départ. Il existe de nombreuses façons de faire la même requête et certaines sont connues pour être plus rapides presque toujours, il est à courte vue de ne pas apprendre et utiliser ces méthodes. Lisez quelques livres sur l'optimisation des performances avant de concevoir des requêtes ou des structures de base de données.

  3. Sécurité - ces données sont vitales pour votre entreprise, elles contiennent également fréquemment des informations personnelles qui peuvent être volées. Apprenez à protéger vos données contre les attaques par injection SQL, la fraude et le vol d'identité.

Lorsque vous interrogez une base de données, il est facile d'obtenir la mauvaise réponse. Assurez-vous de bien comprendre votre modèle de données. N'oubliez pas que les décisions réelles sont souvent prises en fonction des données renvoyées par votre requête. Quand c'est faux, les mauvaises décisions commerciales sont prises. Vous pouvez tuer une entreprise de mauvaises requêtes ou perdre un gros client. Les données ont un sens, les développeurs semblent souvent l'oublier.

Les données ne disparaissent presque jamais, pensez en termes de stockage des données au fil du temps au lieu de savoir comment les obtenir aujourd'hui. Cette base de données qui fonctionnait bien quand elle comptait cent mille enregistrements, n'est peut-être pas aussi belle en dix ans. Les applications durent rarement aussi longtemps que les données. C'est l'une des raisons pour lesquelles la conception axée sur les performances est essentielle.

Votre base de données aura probablement besoin de champs que l'application n'a pas besoin de voir. Des choses comme les GUID pour la réplication, les champs de date insérés. etc. Vous devrez peut-être également stocker l'historique des modifications et qui les a apportées quand et être en mesure de restaurer les modifications incorrectes de ce magasin. Réfléchissez à la façon dont vous avez l'intention de le faire avant de venir demander à un site Web comment résoudre le problème lorsque vous avez oublié de mettre une clause where sur une mise à jour et mis à jour la table entière.

Ne développez jamais dans une version plus récente d'une base de données que la version de production. Ne développez jamais, jamais, jamais directement contre une base de données de production.

Si vous n'avez pas d'administrateur de base de données, assurez-vous que quelqu'un effectue des sauvegardes et sait comment les restaurer et a testé leur restauration.

Le code de base de données est du code, il n'y a aucune excuse pour ne pas le garder en contrôle de code source comme le reste de votre code.


6

Conception de base de données évolutive. http://martinfowler.com/articles/evodb.html

Ces méthodologies agiles rendent le processus de changement de base de données gérable, prévisible et testable.

Les développeurs doivent savoir ce qu'il faut pour refactoriser une base de données de production en termes de contrôle de version, d'intégration continue et de tests automatisés.

Le processus de conception de base de données évolutive a des aspects administratifs, par exemple une colonne doit être supprimée après une certaine durée de vie dans toutes les bases de données de cette base de code.

Sachez au moins que le concept et les méthodologies de refactorisation de base de données existent. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

La classification et la description des processus permettent également de mettre en œuvre des outillages pour ces refactorisations.


J'adore le concept de refactoring, mais en ce qui concerne la base de données, le vrai gros problème avec lui est les données persistantes. la refactorisation de la base de données implique souvent une migration des données, ce qui est en réalité difficile, surtout si vous n'êtes autorisé à aucun temps d'arrêt du système. la restauration n'est pas non plus anodine. à mon avis, les difficultés rencontrées dans les stratégies de déploiement + restauration correctes / sûres sont souvent des éléments incontournables pour refactoriser la base de données aussi légère que le code d'application. lui-même, il est souvent judicieux de refactoriser les choses, mais vous devez toujours l'emporter sur les coûts / avantages.
manuel aldana

Voir aussi «Refactoring Databases» d'Ambler ( amazon.com/Refactoring-Databases-Evolutionary-Database-Design/… ).
Jonathan Leffler

5

D'après mon expérience avec les bases de données relationnelles, chaque développeur doit savoir:

- Les différents types de données :

L'utilisation du type correct pour le travail correct rendra votre conception de base de données plus robuste, vos requêtes plus rapides et votre vie plus facile.

- En savoir plus sur 1xM et MxM :

C'est le pain et le beurre des bases de données relationnelles. Vous devez comprendre les relations un-à-plusieurs et plusieurs-à-plusieurs et postuler ensuite le cas échéant.

- " KISS principe " s'applique également à la DB :

La simplicité fonctionne toujours mieux. À condition d'avoir étudié le fonctionnement de la base de données, vous éviterez une complexité inutile qui entraînera des problèmes de maintenance et de vitesse.

- Indices :

Ce n'est pas suffisant si vous savez ce que c'est. Vous devez comprendre quand les utiliser et quand ne pas les utiliser.


aussi:

  • L'algèbre booléenne est votre amie
  • Images: ne les stockez pas sur la base de données. Ne demandez pas pourquoi.
  • Testez DELETE avec SELECT

+1 pour les images. Je remplacerais cependant «Images» par «BLOBs».
Agnel Kurian

Je ne suis pas vraiment sûr de la partie "simplicité". La base de données la plus simple possible est une table géante avec un tas de varchar(max)colonnes. Les bases de données relationnelles doivent être normalisées et non simplifiées .
Aaronaught

Vos préoccupations sont traitées plus tôt, dans la partie "types de données" de mon message. Je faisais référence à l'utilisation (inutile) des procédures / déclencheurs / curseurs stockés, etc.
Anax

5

J'aimerais que tout le monde, DBA et développeur / concepteur / architecte, comprenne mieux comment modéliser correctement un domaine métier et comment mapper / traduire ce modèle de domaine métier à la fois en modèle logique de base de données normalisée, en modèle physique optimisé et en modèle de classe orienté objet approprié, dont chacun est (peut être) différent, pour diverses raisons, et comprendre quand, pourquoi et comment ils sont (ou devraient être) différents les uns des autres.


5

Je dirais de solides compétences de base en SQL. Jusqu'à présent, j'ai vu beaucoup de développeurs qui connaissent un peu les bases de données mais demandent toujours des conseils sur la façon de formuler une requête assez simple. Les requêtes ne sont pas toujours aussi simples et simples. Vous devez utiliser plusieurs jointures (interne, gauche, etc.) lorsque vous interrogez une base de données bien normalisée.


5

À propos du commentaire suivant à la réponse de Walter M.:

"Très bien écrit! Et la perspective historique est excellente pour les gens qui ne faisaient pas de travail de base de données à l'époque (c'est-à-dire moi)".

La perspective historique est en un certain sens absolument cruciale. "Ceux qui oublient l'histoire sont condamnés à la répéter". Cfr XML répétant les erreurs hiérarchiques du passé, bases de données graphiques répétant les erreurs de réseau du passé, systèmes OO forçant le modèle hiérarchique sur les utilisateurs tandis que tout le monde avec seulement un dixième du cerveau devrait savoir que le modèle hiérarchique n'est pas adapté pour le général représentation de but du monde réel, etcetera, etcetera.

Quant à la question elle-même:

Chaque développeur de base de données doit savoir que «relationnel» n'est pas égal à «SQL». Ensuite, ils comprendraient pourquoi ils sont abîmés si abominablement par les fournisseurs de SGBD, et pourquoi ils devraient dire à ces mêmes fournisseurs de proposer de meilleures choses (par exemple, des SGBD qui sont vraiment relationnels) s'ils veulent continuer à sucer des quantités hilarantes de l'argent de leurs clients pour de tels logiciels de merde).

Et chaque développeur de base de données doit tout savoir sur l'algèbre relationnelle. Ensuite, il n'y aurait plus un seul développeur qui devrait publier ces stupides questions "Je ne sais pas comment faire mon travail et je veux que quelqu'un d'autre le fasse pour moi" sur Stack Overflow.


1
Je conviens qu'un développeur doit savoir où SQL et RDM divergent. Cela dit, une utilisation judicieuse du RDM peut être une aide précieuse pour le concepteur de base de données, même si l'implémentation est SQL.
Walter Mitty

1
Au cas où vous auriez oublié, George Santayana, a écrit cette citation classique ...
crosenblum

5

Je pense que beaucoup de détails techniques ont été abordés ici et je ne veux pas les ajouter. La seule chose que je veux dire est plus sociale que technique, ne tombez pas dans le piège "DBA connaissant le meilleur" en tant que développeur d'application.

Si vous rencontrez des problèmes de performances avec la requête, prenez également en charge le problème. Faites vos propres recherches et incitez les administrateurs de base de données à expliquer ce qui se passe et comment leurs solutions résolvent le problème.

Venez aussi avec vos propres suggestions après avoir fait la recherche. Autrement dit, j'essaie de trouver une solution coopérative au problème plutôt que de laisser les problèmes de base de données aux administrateurs de base de données.


bonne réponse. Nous avons chacun notre propre domaine, nous contribuons à chaque problème ou solution.
crosenblum

5

Respect simple.

  • Ce n'est pas seulement un référentiel
  • Vous ne savez probablement pas mieux que le fournisseur ou les administrateurs de base de données
  • Vous ne le soutiendrez pas à 3 heures du matin, les cadres supérieurs vous criant dessus

3

Considérez la dénormalisation comme un ange possible, pas le diable, et considérez également les bases de données NoSQL comme une alternative aux bases de données relationnelles.

De plus, je pense que le modèle Entity-Relation est un incontournable pour tout développeur, même si vous ne concevez pas de bases de données. Il vous permettra de bien comprendre en quoi consiste votre base de données.


3

N'insérez jamais de données avec un mauvais encodage de texte.

Une fois que votre base de données est polluée par plusieurs encodages, le mieux que vous puissiez faire est d'appliquer une sorte de combinaison d'heuristique et de travail manuel.


2
Qu'est-ce que le "mauvais encodage de texte" et comment cela se produit-il?
Gennady Vanin Геннадий Ванин

1
@ vgv8, cela se produit lorsque votre client autorise les utilisateurs à soumettre du texte dans l'encodage de votre choix, vous le stockez aveuglément. Ensuite, lorsque vous devez effectuer une sorte de transformation ou d'analyse, votre code se casse, car votre application suppose utf-8, mais un idiot a ajouté des données utf-16 et vos erreurs de programme ou commencent à cracher du charabia.
mikerobi

3

Outre la syntaxe et les options conceptuelles qu'ils utilisent (telles que les jointures, les déclencheurs et les procédures stockées), une chose qui sera critique pour tout développeur utilisant une base de données est la suivante:

Sachez comment votre moteur va exécuter la requête que vous écrivez avec spécificité.

La raison pour laquelle je pense que c'est si important est simplement la stabilité de la production. Vous devez savoir comment fonctionne votre code afin de ne pas arrêter toute exécution dans votre thread pendant que vous attendez qu'une longue fonction se termine, alors pourquoi ne voudriez-vous pas savoir comment votre requête affectera la base de données, votre programme et peut-être même le serveur?

C'est en fait quelque chose qui a frappé mon équipe R&D plus de fois que les points-virgules manquants ou similaires. La présomption est que la requête s'exécutera rapidement car elle le fait sur leur système de développement avec seulement quelques milliers de lignes dans les tables. Même si la base de données de production est de la même taille, elle sera plus que probablement utilisée beaucoup plus, et souffrira donc d'autres contraintes comme plusieurs utilisateurs y accédant en même temps, ou quelque chose qui ne va pas avec une autre requête ailleurs, retardant ainsi le résultat de cette requête.

Même des choses simples comme la façon dont les jointures affectent les performances d'une requête sont inestimables en production. Il existe de nombreuses fonctionnalités de nombreux moteurs de base de données qui facilitent les choses sur le plan conceptuel, mais peuvent introduire des pièges dans les performances si elles ne sont pas pensées clairement.

Connaissez votre processus d'exécution de moteur de base de données et planifiez-le.


3

Pour un développeur professionnel intermédiaire qui utilise beaucoup de bases de données (rédaction / maintenance de requêtes quotidiennement ou presque quotidiennement), je pense que l'attente devrait être la même que dans n'importe quel autre domaine: vous en avez écrit une au collège .

Chaque geek C ++ a écrit une classe de cordes au collège. Chaque geek graphique a écrit un raytracer à l'université. Chaque geek Web a écrit des sites Web interactifs (généralement avant que nous ayons des «cadres Web») au collège. Chaque nerd matériel (et même les nerds logiciels) a construit un CPU au collège. Chaque médecin a disséqué un cadavre entier à l'université, même si elle ne prend que ma tension artérielle et me dit que mon cholestérol est trop élevé aujourd'hui. Pourquoi les bases de données seraient-elles différentes?

Malheureusement, ils semblent différents, aujourd'hui, pour une raison quelconque. Les gens veulent que les programmeurs .NET sachent comment les chaînes fonctionnent en C , mais les éléments internes de votre SGBDR ne devraient pas trop vous préoccuper .

Il est pratiquement impossible d'obtenir le même niveau de compréhension en lisant simplement à leur sujet ou même en descendant par le haut. Mais si vous commencez par le bas et comprenez chaque pièce, il est relativement facile de comprendre les spécificités de votre base de données. Même des choses que beaucoup de geeks de bases de données ne semblent pas pouvoir comprendre, comme quand utiliser une base de données non relationnelle.

C'est peut-être un peu strict, surtout si vous n'avez pas étudié l'informatique à l'université. Je vais atténuer certains: vous pouvez en écrire un aujourd'hui , complètement, à partir de zéro. Je me fiche que vous connaissiez les détails du fonctionnement de l'optimiseur de requêtes PostgreSQL, mais si vous en savez assez pour en écrire un vous-même, ce ne sera probablement pas trop différent de ce qu'ils ont fait. Et vous savez, ce n'est vraiment pas si difficile d'en écrire un de base.


De l'article Joel lié sur les chaînes C, l'extrait de code de conduite suivant ne conduit pas à un comportement non défini: char * str = "* Hello!"; str [0] = strlen (str) - 1; str est un littéral de chaîne et est généralement en mémoire morte. Vous ne pouvez pas y écrire :?
HeretoLearn

Un expert en base de données professionnel, très bien, mais chaque développeur ?
Ben Aston

Ben: Tout développeur professionnel qui utilise fréquemment des bases de données, oui. Ils ne sont vraiment pas si difficiles, donc si vous ne savez pas comment, cela signifie que vous n'avez jamais pris même un peu de temps pour apprendre comment fonctionnent les bases de données. Chaque diplôme en informatique avec lequel j'ai obtenu mon diplôme a conçu un processeur et mis en œuvre un système d'exploitation. Une base de données est plus simple que l'un ou l'autre, donc si vous passez du temps à en utiliser une, je ne vois pas d'excuse pour ne pas savoir comment elles fonctionnent.
Ken

2

L'ordre des colonnes dans un index non unique est important.

La première colonne doit être celle qui présente le plus de variabilité dans son contenu (c'est-à-dire la cardinalité).

Cela permet à SQL Server de créer des statistiques utiles sur la façon d'utiliser l'index lors de l'exécution.


-1 Je ne suis pas une bonne idée de suivre des règles comme «La première colonne doit être la colonne qui a le plus de variabilité dans son contenu». Si l'on a des connaissances de base sur le fonctionnement des index, il est simple de voir comment l'ordre est important et que l'ordre de la colonne doit dépendre de la façon dont la table sera interrogée.
miracle173

merci, mais si l'index a été créé sur 3 champs, sur la base qu'une requête SQL spécifique utilisera ces 3 champs dans sa clause where, alors, l'ordre peut être significatif, et le champ avec la cardinalité la plus élevée apparaissant en premier \ plus tôt peut conduire à des améliorations de performances .... ou du moins c'est ce que je lis dans un livre de réglage des performances de Microsoft SQL Server. Je l'ai essayé et ça a semblé mieux marcher (il y a des années).
Mike D

2

Comprenez les outils que vous utilisez pour programmer la base de données !!!

J'ai perdu tellement de temps à essayer de comprendre pourquoi mon code échouait mystérieusement.

Si vous utilisez .NET, par exemple, vous devez savoir comment utiliser correctement les objets dans l' System.Data.SqlClientespace de noms. Vous devez savoir gérer votreSqlConnection objets pour vous assurer qu'ils sont ouverts, fermés et, si nécessaire, correctement éliminés.

Vous devez savoir que lorsque vous utilisez un SqlDataReader, il est nécessaire de le fermer séparément du vôtre SqlConnection. Vous devez comprendre comment garder les connexions ouvertes, le cas échéant, comment minimiser le nombre d'accès à la base de données (car ils sont relativement coûteux en termes de temps de calcul).


2
  • Compétences de base en SQL.
  • Indexage.
  • Traitez les différentes incarnations de DATE / TIME / TIMESTAMP.
  • Pilote JDBCDocumentation du pour la plate-forme que vous utilisez.
  • Traitez les types de données binaires ( CLOB , BLOB , etc.)

1

Pour certains projets, le modèle orienté objet est meilleur.

Pour d'autres projets, un modèle relationnel est préférable.



1

Compatibilité RDBMS

Vérifiez s'il est nécessaire d'exécuter l'application dans plusieurs SGBDR. Si oui, il pourrait être nécessaire de:

  • éviter les extensions SQL RDBMS
  • éliminer les déclencheurs et stocker les procédures
  • suivre des normes SQL strictes
  • convertir les types de données de champ
  • modifier les niveaux d'isolement des transactions

Sinon, ces questions devraient être traitées séparément et différentes versions (ou configurations) de l'application seraient développées.


1

Ne dépendez pas de l'ordre des lignes renvoyées par une requête SQL.


3
... à moins qu'il n'y ait une ORDER BYclause dedans?
Aaronaught

Et ne l'utilisez pas ORDER BYinutilement car cela ajoute de la charge au serveur SQL
Vivian River

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.