Erreurs de développement de base de données faites par les développeurs d’applications

Question

Quels sont communs erreurs de développement fait par les développeurs d’applications de la base de données ?

Answer 1

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

• Égoïste de la base de données de conception et d'utilisation. Les développeurs sont souvent traiter la base de données personnelles, leur objet persistant magasin sans tenir compte des besoins des autres parties prenantes dans les données. Cela s'applique aussi à la demande des architectes. 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. Reporting et MIS a tendance à être un parent pauvre dans la conception de l'application et de la faire seulement comme une réflexion après coup.

• Abuser de denormalised de données. Trop denormalised de données et d'essayer de le maintenir au sein de l'application est une recette pour les problèmes d'intégrité des données. Utilisation 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 la science de fusée et est en fait assez bonne à faire son travail. Mappage O/R de couches sont assez bons pour faire de l'95% des requêtes sont simples et bien adaptés à 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 que les procédures stockées sont le mal, ce genre d'attitude dogmatique n'a pas sa place sur un projet de logiciel.

• Pas la compréhension de conception de base de données. La Normalisation est votre ami et c'est pas la science de fusée. De rejoindre et de cardinalité sont assez simples concepts - si vous êtes impliqué dans la base de données le développement de l'application il n'y a vraiment aucune excuse pour ne pas les comprendre.

Answer 2

<ol> <li>N’utilisez ne pas le contrôle de version sur le schéma de base de données</li> <li>Travaillant directement contre une base de données en direct</li> <li>Ne pas lire et comprendre les plus avancés de bases de données des concepts (index, les index cluster, contraintes, vues matérialisées, etc.)</li> <li>Avoir omis de tester pour l’évolutivité... données d’essai de seulement 3 ou 4 lignes jamais vous donnera la vraie image du vrai Live</li> </ol>

Answer 3

La sur-utilisation et/ou de dépendance sur des procédures stockées.

Certains développeurs d'applications, voir les procédures stockées comme une extension directe de la couche intermédiaire/frontal code. Cela semble être un trait commun dans la pile de Microsoft aux développeurs, (j'en fais partie, mais j'ai grandi hors de lui) et il produit beaucoup de procédures stockées effectuer la logique d'entreprise complexe et de traitement de flux de travail. C'est beaucoup mieux fait ailleurs.

Les procédures stockées sont utiles dans les cas où il a actuallly été prouvé que certains réel facteur technique nécessite leur utilisation (par exemple, les performances et la sécurité) Par exemple, en gardant l'agrégation/filtrage de grands ensembles de données "près de la data".

J'ai eu récemment pour aider à maintenir et améliorer un grand Delphi application de bureau dont 70% de la logique métier et les règles ont été mises en œuvre en 1400, les procédures stockées SQL Server (le reste dans l'INTERFACE utilisateur de gestionnaires d'événements). C'était un cauchemar, principalement en raison de la difficuly de l'introduction efficace de tests unitaires pour TSQL, le manque d'encapsulation et de mauvais outils (des Débogueurs, des éditeurs).

Travailler avec une équipe Java dans le passé, j'ai vite remarqué que souvent le contraire tient dans cet environnement. Architecte Java m'a dit une fois: "La base de données pour les données, et non du code.".

Ces jours, je pense que c'est une erreur de ne pas considérer stockées procs, mais ils doivent être utilisés avec parcimonie (pas par défaut) dans les situations où elles fournissent des avantages utiles (voir les autres réponses).

Answer 4

Problème numéro un ? Ils testent uniquement sur les bases de données de jouet. Donc ils n’ont aucune idée que leur SQL analysera lorsque la base de données devient grande, et quelqu'un doit venir le long et le fixer plus tard (que vous pouvez entendre le son est mon grincement des dents).