[BDD] Redondance de données ou calcul à chaque consultation?

[EffiK]

Bonjour zebulonien(e)s,

 

Je suis actuelement en train de faire un site internet et pour la gestion, je developpe des fonctions en php.

 

J'ai une base de données avec une table nommée "article" et une autre "rubrique".

Pour la table article, j'ai un identifiant, un titre, une intro, un contenu et une date.

Cette table est lié à la table "rubrique" par une relation (1,1) (0,n).

 

Pour la gestion du site, j'ai régulièrement recours à une donnée qui peut être calculée à chaque fois.

 

Cette données est l'identifiant de la rubrique qui se touve à la racine du site du document en cours de consultation.

 

Exemple: j'affiche l'article numero 32 qui apartient à la rubrique numéro 71 qui elle apartient à la rubrique 23 ainsi de suite... jusqu'à la rubrique se trouvant à la racine du site (rubrique numéro 3).

 

Mon problème est de savoir s'il est mieux de calculer cette donnée à la création et à chaque modification de l'article puis de l'inclure dans la table "article". Ce qui occupe plus d'espace que nécessaire puisque la donnée est calculable.

 

Ou de calculer cette donnée à chaque fois que l'on consulte l'article. Ce qui engendre plus de calcul pour le serveur.

 

Merci de votre attention.

Modifié le 20 avril 2006 par EffiK

[Dylav]

L'idéal est bien entendu d'éviter les redondances. Mais il arrive parfois qu'on doive en créer, la plupart du temps pour des raisons de performance.

 

Ce qu'il ne faut pas oublier lorsqu'on met en place une redondance, c'est que le monde n'est pas parfait, et qu'il existe un risque de divergence. Je veux dire par là que, si le calcul dynamique est remplacé par son résultat figé à un certain moment, il devient difficile d'en faire évoluer l'algorithmique, sauf à faire une reprise de données.

 

Tant qu'il ne s'agit que de totaux précalculés et entretenus à des niveaux de rupture, ce n'est pas très grave : il suffit d'écrire dès le départ un petit programme qui balaiera régulièrement l'ensemble de la structure pour vérifier que ces totaux sont restés cohérents et rectifier les éventuels écarts.

 

Mais, dans ton cas, il semblerait que le calcul que tu exécutes détermine l'emplacement de tes articles dans l'arborescence de la base. Ce qui signifie implicitement qu'en cas de divergence, tu risques de ne plus retrouver tes petits. Et qu'en cas de modification de l'algorithmique, il te faudra envisager une remise à plat de ta base, et un rechargement complet.

 

D'où la nécessité d'examiner la question avec circonspection ! Le plus difficile dans l'histoire, c'est de benchmarker les deux solutions pour déterminer, avant toute autre action, si le jeu de la redondance en vaut la chandelle. Cercle vicieux, car pouvoir comparer nécessite de développer les deux solutions...

[KewlCat]

Perso, je considererais les rubriques comme un "référentiel" donc quelque chose qui ne bouge pas (ou très peu), donc j'en chargerais toute l'arborescence en mémoire afin de rendre plus rapide les accès à la rubrique racine d'un document. L'interêt c'est que ce référentiel ne sera stocké en mémoire qu'une seule fois et servira à chaque fois que tu auras besoin de déterminer un chemin de rubriques pour un article.

En cas de modif sur la table des rubriques, je rechargerais illico le référentiel et voilà !

Autrement, si ton SGBD le permet, tu peux utiliser une requête hierarchique pour parcourir la table des rubriques, ça sera plus rapide et ça t'économisera le stockage d'un arbre en mémoire...

[EffiK]

Bonjour,

 

Merci pour vos réponses.

 

La solution que je voulais adopter était de mettre une entré id-secteur dans ma table 'rubrique'.

Cette entrée serait calculée à la création d'une rubrique ainsi qu'à chaque modification.

 

Si j'ai bien compris ta solution Kewlcat, je devrai créer une table 'arbo' avec comme identifiant l'identifiant de la rubrique et y stocker mon arborescence ou bien stocker cette entrée dans la table 'rubrique'.

Modifié le 27 avril 2006 par EffiK

[KewlCat]

Tiens, quelqu'un a déjà travaillé sur les requêtes hierarchiques entre PHP et MySQL :

http://www.webmaster-hub.com/lofiversion/i...php/t21252.html

 

Je ne suis pas certain d'avoir bien compris les liens qui unissent article / secteur / rubrique... D'après tes premières explications, il me semblait qu'un article était lié à une rubrique, et que cette rubrique pouvait avoir une "rubrique-mère" ( --> une colonne "id de rubrique parent" dans la table des rubriques)... Où viennent se greffer les secteurs là-dedans ?

 

Enfin, mille excuses pour ma méconnaissance de PHP mais j'ai beaucoup progressé en une semaine, et j'ai compris qu'il était impossible de faire ce que je t'avais conseillé : charger définitivement une partie des données en mémoire afin que ces données soient accessibles à tout moment sans avoir à repasser par la BDD. Il est imposible de mettre en place une persistance dans ce langage uniquement scripté...

Donc s'il t'est possible de créer une vue "arbo" (si ton SGBD supporte les vues, sinon il faut faire une table et, si ton SGBD supporte les triggers, la mettre à jour automatiquement) pour stocker la "rubrique-racine" (ou toute l'arborescence) de chaque rubrique, ça serait effectivement une bonne solution, plus rapide qu'un recalcul systématique.

[alex.hitman]

Sinon, il serait possible de faire ta première solution KewlCat, sauf qu'au lieu de charger ces données en mémoire, on les copie dans un fichier que l'on ouvre à chaque fois que nécessaire, et que l'on modifie à chaque changement de l'arborescence.

 

Ouvrir un fichier, c'est en général beaucoup plus rapide qu'une requète sur la BDD. Bon bien sur, tout dépend de la requète et du fichier.

Modifié le 1 mai 2006 par alex.hitman

[KewlCat]

Ouaip, on peut toujours passer par des fichiers, mais l'interêt d'une vue (dans un SGBD) c'est quand même qu'elle peut potentiellement rester en mémoire si on y accède très souvent... enfin, si le SGBD est assez gentil

Détail : si l'on met en place ta solution, comment peut-on déclencher la (re)création du fichier quand les données de la table sont modifiées ? Dans le script php qui met à jour ces données ?

[alex.hitman]

On créé, là encore, un fichier qui contiendra... rien (juste un caractère, histoire de pouvoir faire une mise à jour). C'est donc un fichier très léger. On met à jour ce fichier (donc on remplace son contenu par un caractère, un espace fait l'affaire) à chaque modification de l'arborescence.

 

Ainsi, lorsque l'on veut afficher l'arborescence, on compare la date de dernière modification du fichier vide avec la date de dernière modification du fichier contenant l'arborescence.

 

Si le fichier vide est postérieur au fichier de l'arborescence, on met à jour l'arborescence dans le fameux fichier. Sinon, on charge l'arborescence déjà présente dans le fichier.

 

 

Voila, théoriquement, ça devrait fonctionner.

 

 

Avec la fonction pour récupérer les dates de modification : http://www.php.net/manual/fr/function.filemtime.php

 

 

 

 

ps : j'ai moi-même été confronté à ce "problème" d'arborescence, mais je dois avouer que je n'utilise pas cette solution. Certes, celle que je présente ici est meilleure que celle que j'utilise, mais il n'empêche qu'il faut pour cela que les droits en écriture soient activés, ce qui n'est pas le cas pour tous les hébergeurs. L'application que je développe doit pouvoir fonctionner sur le plus de machines possibles, je n'utilise pas les fichiers...

Modifié le 2 mai 2006 par alex.hitman

[EffiK]

Bonjour à tous.

 

Merci beaucoup pour vos informations.

 

en gros voici la structure de mon site:

 

- rubrique 1 (id-secteur=1)(id-parent=0)

--rubrique 56 (id-secteur=1) (id-parent=1)

--article 10 (id-parent=56)

 

--rubrique 78 (id-secteur=1) (id-parent=56)

--article 51 (id-parent=78)

--article 64 (id-parent=78)

...

 

- rubrique 2 (id-secteur=2)(id-parent=0)

--rubrique 21 (id-secteur=2) (id-parent=2)

--article 112 (id-parent=21)

 

--rubrique 36 (id-secteur=2) (id-parent=21)

--article 15 (id-parent=78)

--article 16 (id-parent=78)

...

 

 

 

Ma BDD aura la structure suivante:

 

table "rubrique" :

- *id_rub*

- titre

- texte

 

table "article":

- *id_art*

- titre

- intro

- texte

- date

- status

 

table "parent_art":

- *id_art*

- id_rub

 

table "parent_rub":

- *id_rub*

- id_parent

 

table "secteur":

- *id_rub*

- id_sect

 

 

La solution que je vais adopter, est la redondance.

Comme tu l'as précisé alex.hitman, il faut que ça soit compatible avec le plus d'herbergeur possible donc je ne préfère pas utiliser la création du fichier.

Et pour finir, la table secteur ne sera pas si grosse que ça donc je préfère économiser les performances.

 

Les rubriques étant assez statiques, a chaque modification d'une rubrique, je recalculerai la table "parent_rub" et "secteur" pour la rubrique modifiée et toutes ses rubriques enfants.

 

 

En tout cas merci beaucoup pour votre aide.