10 erreurs SQL communs

Avouons-le - personne étudie SQL pour le plaisir. Vous utilisez SQL pour créer des applications de bases de données, mais avant que vous pouvez construire un, vous avez besoin d'une base de données. Malheureusement, de nombreux projets vont de travers avant la première ligne de l'application est codée. Si vous ne recevez pas le droit de définition de base de données, votre demande est vouée à l'échec. Voici dix erreurs base de données de création de courants que vous devriez être à l'affût de.

Ne présumez pas que vos clients savent ce qu'ils doivent

Généralement, les clients vous appellent pour concevoir un système de base de données quand ils ont un problème à obtenir l'information dont ils ont besoin parce que leurs méthodes actuelles ne fonctionnent pas. Les clients croient souvent qu'ils ont identifié le problème et sa solution. Ils imaginent que tout ce qu'ils doivent faire est de dire tu Que faire.

Faux. La plupart des utilisateurs ne possèdent pas les connaissances ou les compétences nécessaires pour identifier avec précision le problème, de sorte qu'ils ont peu de chance de déterminer la meilleure solution.

Votre travail consiste à convaincre avec tact votre client que vous êtes un expert en analyse et conception de systèmes et que vous devez faire une analyse correcte de découvrir la cause réelle du problème.

Ne pas ignorer la portée du projet

Votre client vous dit ce qu'il ou elle attend de la nouvelle application au début du projet de développement. Malheureusement, le client oublie presque toujours vous dire quelque chose - généralement plusieurs choses. Tout au long de l'emploi, ces nouvelles exigences surgissent et sont cloués sur le projet.

Si vous êtes payé sur une base de projet plutôt que une base horaire, cette croissance portée peut changer ce qui était autrefois un projet rentable dans un perdant. Assurez-vous que tout ce que vous êtes obligé de livrer est spécifié par écrit avant de commencer le projet.

Ne considérez pas que des facteurs techniques

Problèmes de maximums de coûts, la disponibilité des ressources, les délais et la politique de l'organisation peuvent avoir un effet majeur sur le projet. Ces questions peuvent transformer un projet qui est faisable dans un cauchemar. Assurez-vous que vous comprenez tous les facteurs non techniques pertinentes avant de commencer tout projet de développement.

Ne pas éviter les commentaires des clients

Votre premier réflexe pourrait être à l'écoute des gestionnaires qui vous embaucher. Après tout, les utilisateurs sûr que je ne payez pas vos frais. D'autre part, il peut y avoir une bonne raison pour ignorer les gestionnaires, aussi. Ils ne disposent généralement pas la moindre idée de ce que les utilisateurs ont vraiment besoin. Attendez une minute!

Ne pas ignorer tout le monde ou supposer que vous en savez plus que le gérant ou l'utilisateur sur la façon dont une base de données devrait fonctionner. Commis à la saisie faire généralement pas avoir beaucoup de poids organisationnel, et de nombreux gestionnaires ont qu'une vague de certains aspects du travail que les données commis à la saisie font. Mais vous isoler de l'autre groupe est presque certain d'aboutir à un système qui résout un problème que personne n'a.

Vous ne pouvez pas toujours utiliser votre environnement de développement préféré

Vous avez probablement passé des mois, voire des années de devenir compétent dans l'utilisation d'un environnement de développement particulier SGBD ou de l'application. Mais votre environnement préféré - peu importe ce qu'elle est - a ses forces et faiblesses.

Ainsi, plutôt que bricolé ensemble quelque chose qui est vraiment pas la meilleure solution, serrer les dents. Vous avez deux options: soit monter la courbe d'apprentissage d'un outil plus approprié et ensuite l'utiliser, ou franchement dire à vos clients que leur travail serait mieux fait avec un outil que vous n'êtes pas un expert dans l'utilisation.

Puis suggérer au client embaucher quelqu'un qui peut être productif avec cet outil tout de suite. La conduite professionnelle de ce genre recueille le respect de vos clients. (Malheureusement, si vous travaillez pour une entreprise de la place pour vous-même, que le comportement peut également vous aider à mis à pied ou congédié.)

Ne pas utiliser exclusivement l'architecture de votre système favori

Personne ne peut être un expert en tout. Les systèmes de gestion de base de données qui travaillent dans un environnement de télétraitement sont différentes de celles des systèmes qui fonctionnent en mode client / serveur, le partage des ressources, basé sur le Web, ou dans des environnements de bases de données distribuées. Choisissez la meilleure architecture de toute façon, même si cela signifie passer sur le tas. Ne pas obtenir le travail est mieux que d'obtenir et produire un système qui ne sert pas les besoins du client.

Ne pas concevoir des tables de base de données dans l'isolement

Si vous identifiez de façon incorrecte des objets de données et leurs relations les uns aux autres, vos tables de base de données sont susceptibles d'introduire des erreurs dans les données et de détruire la validité des résultats. Pour concevoir une base de données de son, vous devez tenir compte de l'organisation générale des objets de données et soigneusement déterminer comment ils se rapportent les uns aux autres. Vous devez déterminer ce qui est approprié, compte tenu de l'actuelle de votre client et les besoins prévus.

Ne négligez pas les revues de conception

Même le meilleur concepteur et développeur peuvent manquer points importants qui sont évidentes à quelqu'un regarde la situation sous un angle différent. Présenter votre travail avant un examen formel de conception peut vous rendre plus disciplinée dans votre travail. Un examen professionnel compétent votre conception avant de commencer le développement. Vous devriez avoir un concepteur de la base sur le vérifier, mais vous pouvez montrer au client, aussi.

Ne sautez pas de bêta-test

Même si vous le tester dans tous les sens que vous pouvez penser, l'application est sûr de contenir des modes de défaillance que vous ne découvre pas. Signifie Beta test donnant la demande à des gens qui ne savent pas comment il a été conçu.

Ils sont susceptibles d'avoir des problèmes que vous jamais rencontré parce que vous savez trop sur l'application. Vous pouvez alors corriger les bugs ou les déficits de performance que d'autres trouvent que le produit finira officiellement en service.

Ne pas oublier de documenter votre processus

Si vous pensez que votre demande est si parfait qu'il n'a jamais besoin d'être regardé, même une fois de plus, détrompez-vous. La seule chose que vous pouvez être absolument sûr de ce monde est le changement. Compte là-dessus. Six mois à partir de maintenant, vous ne serez pas se rappeler pourquoi vous avez conçu les choses comme vous l'avez fait, à moins que vous documenter soigneusement ce que vous avez fait et pourquoi vous avez fait ça.

Over-documenter votre travail. Mettre plus en détail que vous croyez qu'il est raisonnable. Il va payer plus tard.