Discussion :

[Bisûnûrs]

Bonjour,

Je suis en train de mettre en place des statistiques de visites sur différentes applications, appelons-les "zone membre" et "zone visiteur" pour simplifier.

Comme le plupart des champs sont identiques, mis à part deux ou trois spécifiques, tous les enregistrements se feront dans une table unique, appelons-la "visites", dont un champ sera nécessaire pour différencier la zone de visite.

Exemple de structure :

Code x :

Sélectionner tout - Visualiser dans une fenêtre à part

id, champ1, champ2, champ3, ..., champ10

où champ1 et champ2 sont spécifiques à la zone membre et champ3 est spécifique à la zone visiteur.

Cette table "visites" risque de se remplir assez rapidement, disons quelques centaines de milliers d'enregistrements par semaine.

Quelle serait la meilleure méthode à adopter pour garder une certaine fluidité dans l'exécution des requêtes sur cette table ?

J'ai déjà pensé à créer des vues, l'une pour la zone membre excluant donc le champ3 et l'autre pour la zone visiteur excluant les champ1 et champ2.
On peut aussi scinder la table "visites" en tables hebdomadaires dont une table merge serait l'union de toutes ces tables.
Peut-être un mixe entre les deux ? Peut-être une autre technique à laquelle je ne pense pas ou que je ne connais pas ?
J'utilise MySQL 5.0.24 donc je ne peux pas utiliser le partitionnage.

Je suis preneur de tous les conseils que vous pourrez m'apporter.

Merci !

[Alain Defrance]

Bonjour,

en terme de conception je pense que l'héritage pourrait être une bonne chose.

par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
VISITE(id_visite, champ_commun1, champ_commun2, ...)
VISITE_MEMBRE(#id_visite, champ_membre1, champ_membre2, ...)
VISITE_VISITEUR(#id_visite, champ_visiteur1, champ_visiteur2, ...)

Il suffit alors d'utiliser une vue utlisant une double jointure externe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE VIEW V_VISITE
AS
SELECT VISITE
FROM VISITE_MEMBRE
LEFT JOIN VISITE_MEMBRE ON VISITE.id_visite = VISITE_MEMBRE.id_visite
LEFT JOIN VISITE_VISITEUR ON VISITE.id_visite = VISITE_VISITEUR.id_visite;

Cette conception me semble plus élégante, l'utilisation des vues permet de ne pas alourdir l'utilisation de la base.

Bien évidement la table VISITE ne se remplira pas moins vite, mais quand on souhaite stocker beaucoup de données il faut bien les mettre quelque part

[Bisûnûrs]

Ca me parait plutôt bien oui, comme conception, mais compliquons un peu la chose. Au lieu de deux applications, mettons en quatre avec un champ commun dans trois des applis. Ca me fait créer un champ identique dans chacune des tables VISITE_%application% ou il faut rajouter une nouvelle couche d'héritage ?
Sachant aussi que chaque fois qu'une application est rajoutée, il faut que ce soit le moyen contraignant possible (exemple d'un champ de la nouvelle application qui se retrouve commun avec un champ spécifique d'une application existante) ...

[Alain Defrance]

Oui dans ce cas les choses se compliquent de manière sérieuse.

En effet une nouvelle couche d'héritage est un moyen de résoudre le problème mais comme tu dois le sentir, il deviendra de plus en plus lourd de gérer ces données.

[Bisûnûrs]

Cette nouvelle couche d'héritage nous donnera en plus du fil à retordre dans le cas d'ajout d'applications, puisqu'il faudra créer un table héritée pour chacune des possibilités de champ commun avec les autres tables. Leur nombre augmentera alors de manière exponentielle ainsi que les jointures qui devront être faites.

Que penses-tu de ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

VISITE(id_visite, champ_commun1, champ_commun2, champ_specifique_a1, champ_specifique_a2, ..., application)

Où VISITE est une table merge sur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
VISITE%année%%num_semaine%( [même champs] )
Exemple :
VISITE200801
[...]
VISITE200852

Avec une vue pour chaque application sur la merge, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE VIEW V_VISITE_MEMBRE
AS
SELECT champ_commun1, ..., champ_spécifique_membre1, ...
FROM VISITE
WHERE application = 'membre';

Et où les tables VISITE%année%%num_semaine% seraient créées à l'aide d'un trigger avant l'INSERT sur la merge vérifiant la semaine selon la date d'insertion, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TRIGGER t_create_table_visite BEFORE INSERT ON visite
   FOR EACH ROW
   BEGIN
      DECLARE @annee AS INT
      DECLARE @num_semaine AS INT
      DECLARE @new_table AS STRING
 
      @annee = DATE_FORMAT(...., NEW.date_visite)
      @num_semaine = DATE_FORMAT(...., NEW.date_visite)
      @new_table = CONCAT("VISITE", @annee, @num_semaine)
 
      CREATE TABLE IF NOT EXISTS @new_table
      [...]
   END//

Après on peut imaginer des vues en plus pour chaque application sur la merge mais pour des années ou des mois choisis (voire même des champs spécifiques) pour ne pas alourdir les traitements.

Et dans le cas d'ajout d'une application, on a juste à rajouter une valeur dans le champ application de type ENUM par exemple, et de créer la vue associée selon le modèle des autres vues.



?

Merci en tout cas pour tes réponses !

[Alain Defrance]

Oui ça me semble bien. J'avoue ne pas avoir pensé au tables merge

Mis à part le fait qu'il ne faudra pas oublier de faire attention de mettre à jour la définition de la table mergé, et vérifier sur combien de table une table merge peut porter au maximum (puisque dans ton cas, il y en aura 52 par ans).
Si la limitation est trop forte, il faudra envisager d'avoir une table mergé par ans, et d'avoir une vue qui fera des unions.