Bonjour amis zéros!

J'aimerais vous faire part d'une discussion intéressante que j'ai eu avec des amis concernant de la bonne utilisation des bases de données.


Selon vous, doit-on stocker dans les BDD uniquement des données brutes, ou également quelques données calculées a partir de ces données brutes?

Un exemple pour illustrer :
Supposons que dans une application gérant des voyages, on ait à stocker des dates d'arrivées et des dates de retour.
Dans l'application qui exploitera cette base de donnée, on a également besoin de connaitre la durée du séjour (date retour - date arrivée).
Doit-on stocker cette donnée dans un champs de la table ou la calculer dans l'application?

• Certains préfèrent la stocker dans la base de données pour économiser des calculs du coté de l'application.
• D'autre préfèrent calculer cette valeur a l'instanciation de l'objet, afin de garder une base de données ne contenant que des données brutes. (moins de données à stocker, moins de requêtes)

Qu'en pensez-vous? Quelle approche suivez-vous? Dans quel cadre? (site web, application cliente?)

Pour ma part, dans une base de donnée il y a donnée
De se fait je l'utilise afin de stocker des données utiles, dans ton exemple à chaque fois qu'on va vouloir savoir la durer du séjour va falloir calculer, sa va augmenter "la complexité" de ton code pour ton programme, alors qu'il suffit juste de la stocker de manière intelligente afin que dès que tu en as besoin tu puissent la récupérer rapidement. De plus pour la calculer il faut récupérer 2 variables dans la BDD.
Mais l'utilisation d'une BDD est à mon sens à utiliser avec astuce, méthode de classification précise.
Par exemple ne pas chaque information dans une table différente. Mais lié les informations dans une table par le biais de colonne, ainsi en reprenant ton exemple tu aurais une table avec la date de départ, la date de retour, et la durée, tout est lié c'est le même sujet, c'est dans la même table.
Avec des noms explicites ont s'y retrouve facilement.

Bon après pour certaines information tu en as pas besoin, exemple, un individu te donne sa date de naissance, tu l'enregistre afin de lui souhaiter joyeux anniversaires mais tu vas pas créer une nouvelle colonne pour son age, tu vas le calculer directement.

Donc il faut utiliser la base de donnée de manière intelligente afin de ne pas surcharger ton code, ni ta base de donnée de choses inutile ou encombrant?

Si tu as une idée précise de ton projet, parles-en un peu on te dira ce qu'est le mieux

EDIT : Il existe différente type de base de donnée, mais dés qu'il s'agit de faire un projet mettant en commun des données, pour l'instant j'utilise toujours une BDD, il existe peut être d'autres solutions meilleures ou moins bien, mais j'avouerai qu'elles m'ont bien aidé pour mon site web, mon programme en c# etc...

Merci MétaniumX pour ta réponse.

Ce n'est pas pour un projet, c'est simplement un débat auquel j'ai eu l'occasion de participer.
L'exemple que je donne est volontairement simpliste, mais il faut imaginer ce cas sur une grande base de données ou le problème apparaitrait de nombreuses fois.

Ta solution est donc un mix entre les 2. C'est ce que j'ai tendance à faire aussi actuellement.
J'ai oublié de préciser : je ne connais que les bases de données de type relationnelles pour l'instant, il faudra que je me me penche sur les NoSQL un de ces jours...

D'autres avis?

Le prix du gigaoctet à considérer est le prix de la RAM.

Pour l'exemple de la durée, ça ne présente pas d'intérêt de la stocker puisque son calcul ne consomme rien et qu'elle se déduit immédiatement de 2 colonnes de la même table...

Par contre ça peut être intéressant de dénormaliser quand :

- Le calcul est long et compliqué (c'est une forme de cache) par exemple parser du bbcode en html, c'est très lent, donc on stocke le html prêt à afficher, et le bbcode dans une table à part qui ne sert que pour les éditions de posts.

- Ca permet d'optimiser ou de virer carrément un JOIN qui autrement serait très lent (exemple typique, attributs avec index gist sur INTEGER[] dans postgres)