Que doit savoir chaque développeur sur les bases de données?
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.
pvote 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 pas voter contre 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.
La toute première chose que les développeurs doivent 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 l'heydey des bases de données, des années 1970 au début des années 1990, les bases de données étaient pour le partage de données. Si vous utilisiez une base de données, et vous étiez t en partageant des données vous étiez impliqué dans un projet académique ou 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. Construire une base de données pour MySQL , ou Access , ou SQL Server est devenu si routinier que les bases de données sont devenues presque une partie routinière 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 l'ensemble de la vue centrée sur les données du monde. 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 en réalité une analyse des besoins 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 utilisé beaucoup plus 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 alors que la vitesse (performances) est importante, d'autres mesures de la qualité de la conception sont encore plus importantes , telles que la capacité à réviser et é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!
Bonne question. Voici quelques réflexions sans ordre particulier:
La normalisation, au moins jusqu'à la deuxième forme normale, est essentielle.
L'intégrité référentielle est également essentielle, avec des considérations appropriées de suppression et de mise à jour en cascade.
Bonne et bonne utilisation des contraintes de vérification. Laissez la base de données faire autant de travail que possible.
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.
Décidez d'une approche cohérente pour les clés primaires et les clés en cluster.
Ne pas trop indexer. Choisissez judicieusement vos index.
Nommage cohérent des tables et des colonnes. Choisissez un standard et respectez-le.
Limitez le nombre de colonnes de la base de données qui accepteront des valeurs nulles.
Ne vous laissez pas emporter par les déclencheurs. Ils ont leur utilité mais peuvent compliquer les choses à la hâte.
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.
Obtenez le livre de Celko sur la conception de bases de données. L'homme est arrogant mais connaît son affaire.
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 ensembles 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 qu'ils devraient 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.
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 n'êtes pas conception 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-modèle 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 profitez ou non avec les requêtes que vous écrivez - représente de loin le bloc de performances le plus important. 9 questions sur 10 postées sur SO et d'autres forums se plaignant de mauvaises performances se révèlent invariablement en raison d'une mauvaise indexation ou d'une expression non discutable.
Normalisation
Cela me déprime toujours de voir quelqu'un qui a 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.
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 " n index rend la requête rapide ".
C'est parce que les bases de données SQL font un très bon travail fonctionnant comme 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 fait le système 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.
Clause de non-responsabilité
Les arguments sont empruntés à la préface de mon eBook gratuit " se The Index, Luke ". Je passe beaucoup de temps à expliquer comment fonctionnent les index et comment les utiliser correctement.
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 reporté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 un concept 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, notamment l'environnement, le volume utilisateur et le matériel local disponible tel que l'espace disque dur.
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 effectuez 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 dans l'arbre 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.
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.
Excellente question. Voyons, tout d'abord, personne ne devrait envisager d'interroger une base de données qui ne comprend pas parfaitement 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:
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.
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.
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 agréable 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 effectuées à quel moment 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 la base de données est du code, il n'y a aucune excuse pour ne pas le garder dans le contrôle de code source comme le reste de votre code.
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 refaçonner 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.
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 du "DBA connaissant le meilleur" en tant que développeur d'applications.
Si vous rencontrez des problèmes de performances avec la requête, prenez également en charge le problème. Faites vos propres recherches et faites pression pour que les administrateurs de base de données expliquent 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.
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.
- Le principe " K.I.S.S. " s'applique également au DB :
La simplicité fonctionne toujours mieux. Si vous avez étudié le fonctionnement de DB, 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.
également:
- 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
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.
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
À 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 réseau du passé, OO systèmes forçant le modèle hiérarchique sur les utilisateurs alors que tout le monde avec seulement un dixième du cerveau devrait savoir que le modèle hiérarchique ne convient pas à la représentation à usage général du monde réel, etc., etc.
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 abandonné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.
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.
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 de 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 ainsi 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.
Considérez dénormalisation comme un ange possible, pas le diable, et considérez également 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.
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.
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 pour tout autre domaine: Vous en a écrit un 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 internaute 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 savent comment les chaînes fonctionnent en C , mais les éléments internes de votre SGBDR ne devraient pas trop vous inquiéter .
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 en 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.
- Compétences de base en SQL.
- Indexage.
- Traitez les différentes incarnations de DATE/TIME/TIMESTAMP.
- pilote JDBC documentation pour la plateforme que vous utilisez.
- Traitez les types de données binaires ( CLOB , BLOB , etc.)
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.
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 le System.Data.SqlClient espace de noms. Vous devez savoir comment gérer vos objets SqlConnection 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 de votre 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).
Le problème de non-concordance d'impédance, et connaître les déficiences communes ou ORM.
Trois (choses) est le nombre magique:
Votre base de données a également besoin d'un contrôle de version.
Les curseurs sont lent et vous n'en avez probablement pas besoin.
Les déclencheurs sont mauvais *
*presque toujours
Compatibilité RDBMS
Vérifiez s'il est nécessaire d'exécuter l'application dans plusieurs RDBMS. 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.
Pour certains projets, le modèle orienté objet est meilleur.
Pour d'autres projets, un modèle relationnel est préférable.
Ne dépendez pas de l'ordre des lignes renvoyées par une requête SQL.