Ce que chaque développeur savoir sur les bases de données?

Question

Qu'on le veuille ou non, beaucoup de gens, sinon la plupart d'entre nous soit les développeurs travaillent régulièrement avec des bases de données ou peut-être travailler avec un un jour. Et compte tenu de la quantité de mésusage et l'abus dans la nature et le volume des données, les questions tous les jours, il est juste de dire qu'il y a certaines notions que les développeurs doivent savoir - même si elles ne sont pas de conception, ou de travailler avec des bases de données aujourd'hui. Donc:

---

Quels sont les concepts importants que les développeurs et autres professionnels du logiciel devrait savoir sur les bases de données?

Lignes directrices pour les Réponses:

---

Gardez votre liste courte.
Un concept par répondre.

Être spécifique.
"La modélisation des données" peut être une importante compétence, mais que signifie précisément?

Expliquez votre raisonnement.
Pourquoi votre concept est-il important? Ne pas se contenter de dire "utiliser les index." Ne tombez pas dans les "meilleures pratiques". Convaincre votre auditoire pour aller en apprendre plus.

Upvote réponses vous êtes d'accord avec.
Lire les réponses des autres en premier. Un haut-classé réponse la plus efficace est de déclaration de deux bas-classé. Si vous avez plus à ajouter, ajouter un commentaire ou une référence à l'original.

Ne pas downvote quelque chose juste parce que ça ne s'applique pas pour vous personnellement.
Nous travaillons tous dans des domaines différents. L'objectif ici est de fournir une orientation pour la base de données novices d'acquérir un bien-fondé, la connaissance complète de conception de base de données et de bases de données axées sur le développement, pas de concourir pour le titre de plus important.

Answer 1

La première chose que les développeurs devraient savoir à propos des bases de données est ceci: ce sont des bases de données pour? Pas comment ils travaillent, ni comment faire, ni même comment écrire du code pour récupérer ou mettre à jour les données dans une base de données. Mais quels sont-ils?

Malheureusement, la réponse à cette une est une cible mouvante. Dans le heydey des bases de données, des années 1970 jusqu'au début des années 1990, les bases de données ont été pour le partage de données. Si vous utilisez une base de données, et vous n'avez pas de partage de données vous avez été impliqué dans un projet académique ou de gaspiller des ressources, y compris vous-même. Configuration d'une base de données et de dompter un SGBD étaient telles monumental tâches que le retour sur investissement, en termes de données exploitée à plusieurs reprises, a dû être énorme pour correspondre à l'investissement.

Au cours des 15 dernières années, les bases de données ont été utilisées pour stocker les données persistantes associées à une application. La construction d'une base de données pour MySQLou Accessou SQL Server est devenu la routine que les bases de données sont devenus presque une partie de la routine d'une application ordinaire. Parfois, c'initiale limitée mission est poussé vers le haut par la dérive de la mission, que la valeur réelle des données devient apparente. Malheureusement, les bases de données qui ont été conçus avec un seul but à l'esprit omettent souvent de façon spectaculaire quand ils commencent à être poussé dans un rôle qui est à l'échelle de l'entreprise à mission critique.

La deuxième chose que les développeurs ont besoin d'apprendre au sujet des bases de données est l'ensemble centré sur les données de la vue du monde. Les données centrée sur la vision du monde est différente de processus centré sur la vision du monde que tout, la plupart des développeurs ont jamais appris. Par rapport à cet écart, l'écart entre la programmation structurée et orientée objet de la programmation est relativement faible.

La troisième chose que les développeurs ont besoin d'apprendre, au moins dans une vue d'ensemble, est la modélisation de données, y compris conceptuel de modélisation des données, la logique de la modélisation de données, de la physique et de la modélisation de données.

Conceptuel de données de la modélisation est vraiment l'analyse des besoins à partir de données centrée sur le point de vue.

Logique de la modélisation de données est généralement l'application d'un modèle de données spécifique aux exigences découvert dans conceptuel de modélisation de données. Le modèle relationnel est utilisé beaucoup plus que n'importe quel autre modèle spécifique, et les développeurs ont besoin pour apprendre le modèle relationnel pour vous. La conception d'une puissante et pertinente du modèle relationnel pour un non trivial exigence n'est pas une tâche triviale. Vous ne pouvez pas établir de bonnes tables SQL si vous ne comprenez pas le modèle relationnel.

Physique de la modélisation de données est généralement SGBD spécifique, et n'a pas besoin d'être appris dans les détails, sauf si le développeur est également la base de données du constructeur ou de l'administrateur de la base. Ce que font les développeurs ont besoin de comprendre est la mesure physique de conception de base de données peut être séparée de la logique de conception de base de données, et la mesure dans laquelle la production d'une haute vitesse de base de données peut être accompli simplement en jouant sur la conception physique.

La prochaine chose que les développeurs ont besoin pour apprendre, c'est que même si la vitesse (de la performance) est important, d'autres mesures de la conception de la bonté sont encore plus importants, comme la possibilité de réviser et d'élargir le champ d'application de la base de données en bas de la route, ou la simplicité de la programmation.

Enfin, quelqu'un qui mess avec les bases de données doit comprendre que la valeur des données souvent dure plus longtemps que le système de capture.

Ouf!

Answer 2

Bonne question. Voici quelques pensées sans ordre particulier:

1. La normalisation, au moins à la deuxième forme normale, est essentiel.

2. L'intégrité référentielle est également essentiel, avec une bonne suppression en cascade et mise à jour de considérations.

3. Bon et la bonne utilisation de la vérification des contraintes. Laisser la base de données faire autant de travail que possible.

4. Ne pas disperser les logiques de la base de données et du niveau intermédiaire de code. Choisir l'un ou l'autre, de préférence en milieu de niveau code.

5. Décider sur une approche cohérente pour les clés primaires et les clés ordonnées.

6. N'ayez pas d'index. Choisissez votre index à bon escient.

7. Cohérente de la table et de la colonne de nommage. Choisir un standard et de s'y tenir.

8. Limiter le nombre de colonnes dans la base de données qui permettra d'accepter les valeurs null.

9. Ne vous laissez pas emporter avec des déclencheurs. Ils ont leur utilité, mais peut compliquer les choses à la hâte.

10. Soyez prudent avec l'Udf. Ils sont grands, mais peut entraîner des problèmes de performances lorsque vous n'êtes pas conscients de la façon dont souvent ils risquent d'être appelé dans une requête.

11. Obtenir Celko du livre sur la conception de base de données. L'homme est arrogant, mais connaît son affaire.

Answer 3

Tout d'abord, les développeurs ont besoin de comprendre qu'il y a quelque chose à savoir sur les bases de données. Ils ne sont pas tout simplement magique périphériques où vous avez mis dans le SQL et de sortir des jeux de résultats, mais plutôt très compliqué morceaux de logiciel avec leur propre logique et de bizarreries.

Deuxièmement, qu'il existe différents de la base de données des configurations pour des fins différentes. Vous ne voulez pas un développeur historique de rapports à partir d'une ligne de base de données transactionnelle si il y a un entrepôt de données disponibles.

Troisièmement, les développeurs ont besoin de comprendre SQL de base, y compris des jointures.

Passé cela, il dépend de la façon dont étroitement les développeurs sont impliqués. J'ai travaillé dans des emplois où j'ai été développeur et de facto DBA, où les Administrateurs de bases de données étaient juste en bas de l'allée, et où les Administrateurs de bases de données sont 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 base de données:

Ils doivent comprendre la base de la normalisation, au moins les trois premières formes normales. En dehors de cela, obtenir un DBA. Pour les personnes ayant une expérience avec NOUS, les salles d'audience (et au hasard des émissions de télévision compter ici), il y a le mnémonique "Dépendent de la clé, la clé, et la clé, afin de vous aider à Codd."

Ils doivent avoir une idée sur les index, par qui je veux dire qu'ils doivent avoir une idée de quels indices ils ont besoin et comment ils sont susceptibles d'affecter les performances. Cela signifie ne pas avoir inutiles indices, mais ne pas avoir peur de les ajouter à aider les requêtes. Rien d'autre (comme la balance) ne doit être laissé pour le DBA.

Ils ont besoin de comprendre la nécessité de l'intégrité des données, et être capable de pointer où ils sont en train de vérifier les données et ce qu'ils font, si ils trouvent des problèmes. Ce n'est pas 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 doivent avoir les connaissances de base de la façon d'obtenir un plan, et comment les lire en général (au moins assez pour dire si les algorithmes sont efficaces ou pas).

Ils doivent savoir vaguement ce qu'est un déclencheur est, de ce point de vue est, et qu'il est possible de partition morceaux de bases de données. Ils n'ont pas besoin de toute sorte de détails, mais ils ont besoin de savoir à demander à l'administrateur de la base au sujet de ces choses.

Ils doivent connaître bien sûr de ne pas se mêler avec les données de production, ou le code de production, ou quelque chose comme ça, et ils doivent savoir que tout le code source va dans un CV.

J'ai sans doute oublié quelque chose, mais la moyenne développeur n'a pas besoin d'être un administrateur de base, à condition qu'il existe un réel DBA à la main.

Answer 4

Base D'Indexation

Je suis toujours choqué de voir un tableau ou une base de données entière sans index, ou arbitraire/inutile d'index. Même si vous n'êtes pas de la conception de la base de données et simplement écrire certaines requêtes, il est toujours essentiel de comprendre, au minimum:

• Ce qui est indexé dans votre base de données et ce n'est pas:
• La différence entre les types de scans, la façon dont ils sont choisis, et la manière dont vous écrivez une requête peut influer sur ce choix;
• Le concept de la couverture (pourquoi vous ne devriez pas simplement écrire SELECT *);
• La différence entre un cluster et index non ordonné en clusters;
• Pourquoi de plus en plus/de plus grands indices ne sont pas nécessairement mieux;
• Pourquoi vous devriez essayer d'éviter d'emballage filtrer les colonnes dans les fonctions.

Les concepteurs doivent également être conscients de la commune de l'indice des anti-modèles, par exemple:

• L'Accès anti-modèle (indexation de chaque colonne, un par un)
• Fourre-Tout, anti-modèle (un énorme indice sur la totalité ou la plupart des colonnes, apparemment créé sous l'impression erronée qu'il permettrait d'accélérer tous les moyens imaginables de la requête concernant une de ces colonnes).

La qualité d'une base de données d'indexation de l' - et si oui ou non vous de prendre avantage de celui-ci avec les requêtes que vous écrivez - représente de loin la plus importante partie de la performance. 9 des 10 questions posées sur, et d'autres forums se plaindre de la mauvaise performance, invariablement dues à une mauvaise indexation ou un non-sargable expression.

Answer 5

La normalisation

Elle toujours me déprime de voir quelqu'un de la difficulté à écrire une excessive complexité de la requête qui aurait été complètement simple avec une conception normalisée ("Montrez-moi le total des ventes par région.").

Si vous comprenez cela, au début et à la conception en conséquence, vous vous épargnerez beaucoup de douleur plus tard. Il est facile à éliminer pour la performance après avoir normalisé; il n'est pas si facile à normaliser une base de données qui n'a pas été conçu de cette façon depuis le début.

À tout le moins, vous devez savoir ce 3FN est et comment s'y rendre. Avec la plupart des bases de données transactionnelles, c'est un très bon équilibre entre la prise de requêtes facile à écrire et à maintenir de bonnes performances.