Yop, je me demandais pour les vérifications "benignes" telles vérifier que la date de naissance de l'utilisateur est plausible (entre 13 et 100 ans admettons). Est-ce préférable de faire le test en SQL avec un CHECK ou depuis le langage utilisé (PHP, Python, Java...) ?

EDIT : Ou encore pour une verification de la forme d'une adresse email.

Merci d'avance.

Cela dépend de tes préférences et des capacités de ton SGBDR ...

Personnellement, j'ai tendance à mettre toutes les vérifications sur le serveur, pour m'assurer que la base de données est toujours consistente. Certains disent que c'est une perte de temps car il faut une communication avec le serveur SQL, parce qu'on a moins de "visibilité" avec une règle SQL que dans le code, etc.

Cela dépend de ce que tu attends d'un SGBDR. Au risque d'être réducteur pour les langages hôtes, personnellement je le vois comme le coeur de mon application, le reste du code consistant essentiellement en l'interface utilisateur ...

Ceci dit, il s'agit d'un débat, je pense que toutes les méthodes se défendent :-) Et puis SQL, on aime ou on n'aime pas

Merci pour ta réponse, je trouve ton point de vu très intéressant. Par contre celà complique légèrement les choses. Il faut créer des types genre "md5" pour les mots de passe, type e-mail... (et je crois qu'avec PostGres il faut créer les types de base en C o_O)

Sous postgres tu peux utiliser du C pour créer des types. C'est très utile (par exemple tous les types un peu évolués comme array[] ou polygone sont en C ce qui les rend rapides) mais c'est très rare que l'utilisateur final ait à y toucher.

La plupart du temps un type de base + une contrainte CHECK suffit, ou un domaine (CREATE DOMAIN).

Pour tes exemples :

- le mot de passe crypté : c'est un TEXT tout bête (en hexa), ou alors un BYTEA (en binaire). Tu peux rajouter un CHECK pour la longueur et que c'est bien de l'hexa...

- l'email : idem, texte + CHECK, mais bon si tu valides dans l'appli que c'est bien un email (en envoyant un email au type avec lien à cliquer) c'est pas la peine d'en remettre une couche dans la BDD !

Personnellement, je te conseillerais d'attribuer un rôle un peu plus important à ta base de données que celle du simple stockage. Si le SGBD ne fait aucune vérification (autre que la contrainte de typage), il suffirait d'une faille, bug ou autre dans ton application pour que l'utilisateur puisse insérer n'importe quoi dans la BDD et ainsi rendre incohérentes les informations qui s'y trouvent.

Mais là c'est mon côté "DBA" qui parle , après tout dépend du contexte dans lequel l'application évolue.
Si tu ne veux pas te prendre la tête, que tu es seul à développer tes applis en étant plus ou moins sûr de ce que tu codes et que les données ne sont pas critiques, alors une simple vérification in-code est peut-être suffisante.

Je pense que la bonne réonse est "les deux". L'exemple typique est l'appli web. Si tu peux détecter en javascript par exemple que les données saisies sont fausse, ce n'est pas la peine d'envoyer une requête HTTP, suivie d'une requête SQL, pour récolter une erreur. Mais la base ne doit *surtout pas* accepter quoi que ce soit d'incohérent. Donc contraintes partout. De plus on n'a aucune garantie sur l'origine d'une requête - ce peut-être une appli qui filtre bien, ou un client interactif SQL (voire, horreur, Excel avec ODBC) qui ne vérifie rien du tout, un navigateur pour lequel javascript a été désactivé, un hacker ... Tu vois les châteaux-forts? La base, c'est le donjon. Mais cela n'empêche pas les murs d'enceinte.

Merci à tous pour vos réponses. C'est beaucoup plus clair maintenant

Je suis encore en école d'info et je savais même pas que la BDD pouvait faire des vérifications de données, vous avez l'air de dire que c'est bien.

Vous les faites quand vos vérifications ? Au moment de la requête SQL ? (INSERT ... CHECK ) ? Ou ailleurs ?

Ca consomme beaucoup de ressources serveur ?

Non, au moment de la création de la table, ça serait un peu lourd de faire ça à chaque insertion Et peu logique puisqu'il suffirait d'oublier (volontairement ou pas) le CHECK pour que la base ne soit plus cohérente.

http://www.postgresql.org/docs/8.4/sta [...] atetable.html Renseignes toi sur les constraints http://www.postgresql.org/docs/8.4/sta [...] straints.html

Merci !

En effet c'est pas mal. Mais je vois mal où les utiliser, les date la BDD les vérifie déjà, même si on pourrait rajouter des contraintes de date min/max, c'est vrai...

J'imagine que si une des contraintes n'est pas respecté la modification/création est annulée ? (Moi et l'anglais ça fait beaucoup de choses, mais pas 2 Même si c'est plutôt simple à comprendre là, heureusement ^^).

Je vois mal comment les utiliser pour mes cas personnels. Tu les utilises majoritairement sur quoi toi ?

Hmm désolé, j'ai l'habitude de regarder les docs en VO XD http://docs.postgresqlfr.org/8.4/ddl-constraints.html

Tu peux les utiliser là où d'habitude tu utilises PHP (par exemple) pour faire des vérifications, comme ça a été dit plus haut.

Ok, merci