par
iclo » 21 avr. 2006, 18:33
Je serais plus mitigé que toi sur la question Ouckileou.
Comme souvent en informatique, c'est une question d'utilisation.
si on sait lors de la conception de la base de donnée, que le champ d'une table ne contiendra jamais de doublon, on a tout intérêt à ajouter une contrainte d'unicité.
Dans le cas d'un "gros système" avec différentes équipes de dévellopement qui travailleront sur des tables communes, un DBA (DataBase Administrator, ceui qui veille sur la Db en gros

) aura tout intérêt à être parano et à faire preuve d'un excès de prudence, face à ces maladroits de programeurs, qui serait capables de ne pas respecter en permanence ces contraintes.
Quand à savoir si il vaut mieux utiliser cette contrainte via un code d'erreur retourné par le serveur, ou une verification par un select au préalable, tout dépend de la fréquence d'insertion, et du risque de "redondance", si le risque est faible,autant ne pas faire un select inutile (qui consomme quand même des ressources sur le serveur) et se contenter d'une gestion d'erreur (dans la grande majorité des cas, un seul appel à la db)
Si parcontre le risque est élevé, alors le select à certains avantage. (deux appel à la db si pas de redondance, un seul si oui)
Je ne comprends pas ce que tu entends par "Et si le serveur rencontre un problème, personne ne pourra s'inscrire, tout en croyant que tous les pseudos possibles et inimaginable sont déjà pris..."
Perso, je préfère le code d'erreur, qui ménage le serveur pour un résultat quasi équivalent au select préalable.
Je serais plus mitigé que toi sur la question Ouckileou.
Comme souvent en informatique, c'est une question d'utilisation.
si on sait lors de la conception de la base de donnée, que le champ d'une table ne contiendra jamais de doublon, on a tout intérêt à ajouter une contrainte d'unicité.
Dans le cas d'un "gros système" avec différentes équipes de dévellopement qui travailleront sur des tables communes, un DBA (DataBase Administrator, ceui qui veille sur la Db en gros :D) aura tout intérêt à être parano et à faire preuve d'un excès de prudence, face à ces maladroits de programeurs, qui serait capables de ne pas respecter en permanence ces contraintes.
Quand à savoir si il vaut mieux utiliser cette contrainte via un code d'erreur retourné par le serveur, ou une verification par un select au préalable, tout dépend de la fréquence d'insertion, et du risque de "redondance", si le risque est faible,autant ne pas faire un select inutile (qui consomme quand même des ressources sur le serveur) et se contenter d'une gestion d'erreur (dans la grande majorité des cas, un seul appel à la db)
Si parcontre le risque est élevé, alors le select à certains avantage. (deux appel à la db si pas de redondance, un seul si oui)
Je ne comprends pas ce que tu entends par "Et si le serveur rencontre un problème, personne ne pourra s'inscrire, tout en croyant que tous les pseudos possibles et inimaginable sont déjà pris..."
Perso, je préfère le code d'erreur, qui ménage le serveur pour un résultat quasi équivalent au select préalable.