Dans la question de vérification d'intégrité par la base de donnée avec des contraintes, la base rejetant les enregistrements fautifs, il faut que le code "capture" le rejet de la base et l'analyse pour expliciter le pourquoi du rejet à l'utilisateur.
oui ! Si t'arrives à faire ça, c'est cool =)
De ce que j'ai vu, le plus souvent, l'analyse de l'erreur se résume à "database error" ou "inconsistent data", pis après, démmerde toi ... :/
N'est-il pas plus facile et plus performant en terme de rapidité de vérifier l'intégrité par le code AVANT insertion, plutôt que de faire un système de gestion d'erreur qui explique ensuite pourquoi la commande n'a pas été effectuée et a été rejetée ?
Excellente question. Pour moi, ça dépend de tes données. Si statistiquement, les incohérences des données en entrée sont rares, la majorité de tes tests d'intégrité en amont ne servira à rien donc tu perds en perfo si tu testes tout avant. Si tes données en entrée sont très souvent moisies, ça peut valoir le coup de faire tes tests de diagnostic avant de tenter l'insertion.
Comme pour *toutes* les questions de perfo, il faut benchmarker avec des données et des volumétrie de prod.
il vaut mieux que ca marche pas sans explications plutôt que ca marche alors qu'il ne faut pas ?
alors là, une seule réponse possible, si les données sont foireuses, il ne faut *pas* que ça marche. La correction (le fait de se comporter correctement) d'un logiciel est une de ses qualités essentielles. Pourquoi ? parce que l'erreur se propage. Si une brique de ton soft laisse passer des données incohérentes, l'incohérence se propage dans tout le reste du soft, et tu as vite fait de te retrouver avec une base de données indémmerdable (données contradictoires, incomplètes, fausses, doublons fonctionnelles, ...) qui entraîne des plantages applicatifs (à moins que le soft ait été codé dès le départ en postulant que les données en base n'étaient pas fiables, et encore ...)
[^] # Re: Mauvaise idée.
Posté par gaaaaaAab . En réponse au message Stocker un tableau dans une base sql. Évalué à 1.
oui ! Si t'arrives à faire ça, c'est cool =)
De ce que j'ai vu, le plus souvent, l'analyse de l'erreur se résume à "database error" ou "inconsistent data", pis après, démmerde toi ... :/
Excellente question. Pour moi, ça dépend de tes données. Si statistiquement, les incohérences des données en entrée sont rares, la majorité de tes tests d'intégrité en amont ne servira à rien donc tu perds en perfo si tu testes tout avant. Si tes données en entrée sont très souvent moisies, ça peut valoir le coup de faire tes tests de diagnostic avant de tenter l'insertion.
Comme pour *toutes* les questions de perfo, il faut benchmarker avec des données et des volumétrie de prod.
alors là, une seule réponse possible, si les données sont foireuses, il ne faut *pas* que ça marche. La correction (le fait de se comporter correctement) d'un logiciel est une de ses qualités essentielles. Pourquoi ? parce que l'erreur se propage. Si une brique de ton soft laisse passer des données incohérentes, l'incohérence se propage dans tout le reste du soft, et tu as vite fait de te retrouver avec une base de données indémmerdable (données contradictoires, incomplètes, fausses, doublons fonctionnelles, ...) qui entraîne des plantages applicatifs (à moins que le soft ait été codé dès le départ en postulant que les données en base n'étaient pas fiables, et encore ...)