une vue permettrait d'accéder à l'information de stock global sans ajouter une table dédiée. Vu les perf des machines actuelles, ça devrait suffire pour beaucoup de cas d'usage, et on pourrait même passer à une vue matérialisée avant d'être vraiment contraint à ajouter une table juste pour ça. La duplication de données dans une DB, perso, je déconseille tant qu'on a des moyens raisonnables de l'éviter.
il est dommage de ne pas éviter de prendre celles dont on sait tôt ou tard qu’elles se présenteront.
Oui, mais pas forcément avec du code.
Là, il y a une question plus générale. Faut-il systématiquement développer du code pour faire face à tous les problèmes qu'on anticipe ? et je crois que la réponse est vraiment non.
Si le problème ne se présente jamais, t'auras développé du code inutile.
Si/Quand un autre problème imprévu se présente, la façon dont tu vas y répondre va peut-être t'amener à devoir jeter une partie du code que t'avais écrit pour anticiper un problème que tu n'as pas encore rencontré.
Ça ne veut pas dire qu'il ne faut rien faire pour gérer les problèmes qu'on anticipe, mais je pense que l'anticipation doit se faire au niveaux des choix d'architecture (pas seulement de l'architecture technique globale, mais aussi de l'architecture du code de chaque module) et des choix techniques. On peut penser les solutions, mais l'implémentation, ça vaut le coup de la délayer jusqu'au moment où le problème menace vraiment de se présenter. C'est une question de gestion de la ressource "temps de développeur".
[^] # Re: table stock
Posté par gaaaaaAab . En réponse au message Sous requêtes et alias. Évalué à 3.
une vue permettrait d'accéder à l'information de stock global sans ajouter une table dédiée. Vu les perf des machines actuelles, ça devrait suffire pour beaucoup de cas d'usage, et on pourrait même passer à une vue matérialisée avant d'être vraiment contraint à ajouter une table juste pour ça. La duplication de données dans une DB, perso, je déconseille tant qu'on a des moyens raisonnables de l'éviter.
Oui, mais pas forcément avec du code.
Là, il y a une question plus générale. Faut-il systématiquement développer du code pour faire face à tous les problèmes qu'on anticipe ? et je crois que la réponse est vraiment non.
Si le problème ne se présente jamais, t'auras développé du code inutile.
Si/Quand un autre problème imprévu se présente, la façon dont tu vas y répondre va peut-être t'amener à devoir jeter une partie du code que t'avais écrit pour anticiper un problème que tu n'as pas encore rencontré.
Ça ne veut pas dire qu'il ne faut rien faire pour gérer les problèmes qu'on anticipe, mais je pense que l'anticipation doit se faire au niveaux des choix d'architecture (pas seulement de l'architecture technique globale, mais aussi de l'architecture du code de chaque module) et des choix techniques. On peut penser les solutions, mais l'implémentation, ça vaut le coup de la délayer jusqu'au moment où le problème menace vraiment de se présenter. C'est une question de gestion de la ressource "temps de développeur".