Prévenir une mauvaise saisie de données

Question

Est-ce une bonne pratique de déléguer entièrement la validation des données aux contraintes du moteur de base de données?

La validation des données de l’application n’empêche pas l’insertion non valide d’un autre logiciel (éventuellement écrite dans une autre langue par une autre équipe). En utilisant des contraintes de base de données, vous réduisez le nombre de points où vous devez vous soucier des données d'entrée non valides.

Si vous mettez la validation à la fois dans la base de données et dans l'application, la maintenance devient ennuyeuse, car vous devez mettre à jour le code pour savoir combien d'applications, ce qui augmente le risque d'erreur humaine.

Je ne vois tout simplement pas que cela se fait beaucoup, en regardant le code de projets de logiciels libres.

Answer 1

Il est préférable, dans la mesure du possible, de spécifier vos règles de validation dans votre base de données et d'utiliser ou d'écrire un cadre qui les fasse bouillonner dans votre frontal. ASP.NET Dynamic Data facilite cette tâche. Certaines bibliothèques commerciales facilitent encore plus les choses.

Cela peut être fait à la fois pour une validation d’entrée simple (comme des nombres ou des dates) et des données connexes comme celle contrainte par des clés étrangères.

En résumé, l’idée est de définir les règles à un endroit (la base de données la plupart du temps) et d’avoir du code dans d’autres couches qui appliqueront ces règles.

Answer 2

Valider au moment de la saisie. Validez à nouveau avant de le mettre dans la base de données. Et avoir des contraintes de base de données pour empêcher une mauvaise saisie. Et vous pouvez parier que malgré tout, de mauvaises données resteront dans votre base de données, alors validez-les à nouveau lorsque vous les utiliserez.

Il semble que tous les jours certaines applications Web soient piratées parce qu'elles utilisaient toutes les validations sous la forme ou pire, en utilisant Javascript, et que les utilisateurs trouvaient le moyen de les contourner. Vous devez vous protéger contre cela.

Paranoïaque? Moi? Non, juste expérimenté.

Answer 3

L'inconvénient de laisser la logique à la base de données est que vous augmentez la charge sur ce serveur particulier. Les serveurs Web et d'applications sont relativement faciles à faire évoluer vers l'extérieur, mais une base de données nécessite des techniques spéciales. En règle générale, il est judicieux de mettre autant de logique de calcul dans la couche application et de garder l'interaction avec la base de données aussi simple que possible.

Cela étant dit, il est possible que votre application n'ait pas à s'inquiéter de problèmes d'évolutivité aussi importants. Si vous êtes certain que la charge du serveur de base de données ne posera pas de problème dans un avenir prévisible, continuez et mettez les contraintes sur la base de données. Vous avez tout à fait raison de dire que cela améliore l'organisation et la simplicité de votre système dans son ensemble en maintenant la logique de validation dans un emplacement central.

Answer 4

Il existe d'autres problèmes que la simple injection SQL avec entrée. Vous devez adopter la position la plus défensive possible lorsque vous acceptez les entrées de l'utilisateur. Par exemple, un utilisateur peut éventuellement entrer un lien vers une image dans une zone de texte, qui est en fait un script PHP qui exécute quelque chose de méchant.

Si vous concevez bien votre application, vous ne devriez pas avoir à vérifier minutieusement toutes les entrées. Par exemple, vous pouvez utiliser une API Forms qui s’occupe de la majeure partie du travail, et une couche de base de données qui fait la même chose.

C’est une bonne ressource pour la vérification de base des vulnérabilités:

http://ha.ckers.org/xss.html

Answer 5

Il est beaucoup trop tard au moment où les données parviennent à votre base de données pour fournir une validation significative à vos utilisateurs et à vos applications. Vous ne voulez pas que votre base de données fasse toutes la validation, car cela ralentirait considérablement les choses, et la base de données n'exprimera pas la logique aussi clairement. De même, à mesure que vous grandissez, vous écrivez davantage de transactions au niveau de l’application pour compléter vos transactions avec la base de données.

Answer 6

Je dirais que c'est potentiellement une mauvaise pratique, selon ce qui se passe lorsque la requête échoue. Par exemple, si votre base de données peut générer une erreur gérée de manière intelligente par une application, vous pouvez vous en tirer.

D'autre part, si vous n'appliquez aucune validation dans votre application, il se peut que vous ne disposiez pas de données erronées, mais que certains utilisateurs pensent peut-être qu'ils ont saisi des éléments qui ne sont pas enregistrés.

Answer 7

Mettez en œuvre autant de validation de données que possible au niveau de la base de données sans compromettre les autres objectifs. Par exemple, si la rapidité est un problème, vous pouvez envisager de ne pas utiliser des clés étrangères, etc. domaines.

Answer 8

Un autre inconvénient de la validation des données à partir de la base de données est que, dans tous les cas, vous ne validez pas la même chose. En fait, cela dépend souvent de la logique de l'application (rôles d'utilisateur) et vous pouvez parfois souhaiter ignorer complètement la validation (travaux cron et scripts de maintenance).

Answer 9

J'ai constaté que la validation dans l'application, plutôt que dans la base de données, fonctionne bien. Bien entendu, toutes les interactions doivent passer par votre application. Si vous avez d'autres applications qui fonctionnent avec vos données, votre application devra prendre en charge une sorte d'API (heureusement REST).

Answer 10

Je ne pense pas qu'il y ait une bonne réponse, cela dépend de votre utilisation.

Si vous utilisez un système très fortement utilisé, avec le potentiel que les performances de la base de données deviennent un goulot d'étranglement, vous voudrez peut-être déplacer la responsabilité de la validation vers le serveur principal où il est plus facile de faire évoluer plusieurs ressources. serveurs.

Si plusieurs applications interagissent avec la base de données, il est possible que vous ne souhaitiez pas répliquer et gérer les règles de validation sur plusieurs applications. La base de données pourrait donc être le meilleur endroit.

Vous voudrez peut-être un écran de saisie plus lisse qui ne frappe pas simplement l'utilisateur avec des avertissements de validation lorsqu'il tente de sauvegarder un enregistrement; vous voudrez peut-être valider un champ après la saisie des données et la perte du focus; ou même lorsque l'utilisateur tape, changer la couleur de la police lorsque la validation échoue / passe.

Les avertissements concernant les données suspectes sont également liés aux contraintes. Dans ma candidature, la base de données contient des contraintes strictes (par exemple, une personne ne peut pas commencer un travail avant sa date de naissance), mais au début elle contient des avertissements concernant des données éventuellement correctes mais suspectes (par exemple, une période de huit ans). -travailler un emploi).