par
tonyrion » 19 juil. 2011, 18:44
Bonjour,
Je me suis lancé dans un projet destiné à décharger du travail de mise à jour manuelle d'un jeu auquel nous prenons part avec des amis depuis quelques années.
Mon exemple sera donc tiré de ce projet et j'espère que vous pourrez m'apporter une réponse claire qui me permettra de pouvoir avancer dans le développement mais surtout de progresser dans ma compréhension des BDD.
J'avais réalisé un site il y a quelques années dans lequel je suivais les résultats d'une équipe de football pour une association avec une partie administration permettant aux personnes habilitées de mettre à jour les données du championnat notamment, de toutes les équipes, avec gestion des buteurs, cartons, temps de jeu, classement, ... Bref une gestion de championnat classique facile à maintenir.
Seulement, au fil des saisons, je me retrouvais avec des tables volumineuses car pour chaque journée, chaque équipe avait une occurence de générée et ce afin d'analyser l'historique des données. Exemple, le classement d'une équipe lors de la 6ème journée alors qu'on en est à la 24°, le classement général de n'importe qu'elle journée, ...
Donc, si on part sur la base d'une championnat à 20 clubs avec de ce fait 38 journées, on arrive à 760 occurences par saison dans la seule table journée.
En même temps à ce rythme je pouvais y aller, avec un seul championnat à gérer la base était loin d'être saturée.
Seulement aujourd'hui mon nouveau projet doit pouvoir permettre de tenir avec beaucoup plus de championnats. En fait mes amis ont un réseau d'autres amis qui ont eux même leur réseau, etc..., sachant que nous avons chacun besoin d'environ 10 championnats et qu'il existe plusieurs centaines de personnes. Donc à l'instant T plusieurs milliers de ligues à gérer.
Dès lors si nous partons sur 760 occurences par ligue et qu'on prend 1000 ligues, nous obtenons par saison 760 000 occurences.
Ca complique les choses.
J'ai donc regardé un peu partout et je me suis demandé si, en regroupant les données contenues sur une ligne pour un club dans le projet précédent dans une chaine et que je mettais les 20 clubs sur une ligne, je divisais déjà par 20 ma consommation en terme d'occurences.
Etant donné que ces données ne serviront de toute manière qu'à la consultation et n'ont donc pas de valeur en terme relationnel dans la BDD, j'ai pensé que la solution serait viable.
Il faudra ensuite traiter ces données via des fonctions en PHP qui seront appelées à chaque fois qu'on en aura besoin à l'affichage ou dans des calculs de stats.
Evidemment la solution est moins facile à entretenir, mais via une console d'administration, si le codage-décodage de ces lignes est bien réalisé, tout sera invisible pour l'utilisateur.
Maintenant je ne trouve pas d'information là dessus.
Tout ce que je lis c'est que lorsqu'on regroupe des données, c'est que les tables sont mal pensées au départ.
Pensez-vous que ce que je cherche à créer est une erreur et inadapté au besoin?
Qu'est ce qui prend le plus de temps et de ressrouces? Une table trop lourde ou le codage-décodage de chaines via des arrays dans des tables plus légères?
Bref, c'est toute la base de mon futur développement que je remet en question, donc merci à vous si vous pouvez me guider sur la solution à adopter.
Si par ailleurs vous avez des exemples de conception de tables pour ce type de projet sur lesquels je pourrais m'appuyer ou que vous avez besoin que je vous présente la structure précise de ce que je voulais faire, merci de le dire.
Bonjour,
Je me suis lancé dans un projet destiné à décharger du travail de mise à jour manuelle d'un jeu auquel nous prenons part avec des amis depuis quelques années.
Mon exemple sera donc tiré de ce projet et j'espère que vous pourrez m'apporter une réponse claire qui me permettra de pouvoir avancer dans le développement mais surtout de progresser dans ma compréhension des BDD.
J'avais réalisé un site il y a quelques années dans lequel je suivais les résultats d'une équipe de football pour une association avec une partie administration permettant aux personnes habilitées de mettre à jour les données du championnat notamment, de toutes les équipes, avec gestion des buteurs, cartons, temps de jeu, classement, ... Bref une gestion de championnat classique facile à maintenir.
Seulement, au fil des saisons, je me retrouvais avec des tables volumineuses car pour chaque journée, chaque équipe avait une occurence de générée et ce afin d'analyser l'historique des données. Exemple, le classement d'une équipe lors de la 6ème journée alors qu'on en est à la 24°, le classement général de n'importe qu'elle journée, ...
Donc, si on part sur la base d'une championnat à 20 clubs avec de ce fait 38 journées, on arrive à 760 occurences par saison dans la seule table journée.
En même temps à ce rythme je pouvais y aller, avec un seul championnat à gérer la base était loin d'être saturée.
Seulement aujourd'hui mon nouveau projet doit pouvoir permettre de tenir avec beaucoup plus de championnats. En fait mes amis ont un réseau d'autres amis qui ont eux même leur réseau, etc..., sachant que nous avons chacun besoin d'environ 10 championnats et qu'il existe plusieurs centaines de personnes. Donc à l'instant T plusieurs milliers de ligues à gérer.
Dès lors si nous partons sur 760 occurences par ligue et qu'on prend 1000 ligues, nous obtenons par saison 760 000 occurences.
Ca complique les choses.
J'ai donc regardé un peu partout et je me suis demandé si, en regroupant les données contenues sur une ligne pour un club dans le projet précédent dans une chaine et que je mettais les 20 clubs sur une ligne, je divisais déjà par 20 ma consommation en terme d'occurences.
Etant donné que ces données ne serviront de toute manière qu'à la consultation et n'ont donc pas de valeur en terme relationnel dans la BDD, j'ai pensé que la solution serait viable.
Il faudra ensuite traiter ces données via des fonctions en PHP qui seront appelées à chaque fois qu'on en aura besoin à l'affichage ou dans des calculs de stats.
Evidemment la solution est moins facile à entretenir, mais via une console d'administration, si le codage-décodage de ces lignes est bien réalisé, tout sera invisible pour l'utilisateur.
Maintenant je ne trouve pas d'information là dessus.
Tout ce que je lis c'est que lorsqu'on regroupe des données, c'est que les tables sont mal pensées au départ.
Pensez-vous que ce que je cherche à créer est une erreur et inadapté au besoin?
Qu'est ce qui prend le plus de temps et de ressrouces? Une table trop lourde ou le codage-décodage de chaines via des arrays dans des tables plus légères?
Bref, c'est toute la base de mon futur développement que je remet en question, donc merci à vous si vous pouvez me guider sur la solution à adopter.
Si par ailleurs vous avez des exemples de conception de tables pour ce type de projet sur lesquels je pourrais m'appuyer ou que vous avez besoin que je vous présente la structure précise de ce que je voulais faire, merci de le dire.
