Discussion :

[Heirem]

Bonjour,
Je cherche un script qui me permettrait de gérer les options d'un site de façon intelligente et optimisée. Le problème venant de la quantité importante d'options à manipuler tout en se basant sur une table MySQL la plus minimale possible. Avec un enregistrement dans une seule table par option.

Le cœur du sujet est de pouvoir stocker dans une rubrique de type longtext ou blob n'importe quel type de données. Et bien entendu de récupérer les données dans leur typage d'origine.

L'autre point important, étant donné le nombre d'options concerné, consiste à pouvoir structurer la table par groupes d'options afin d'optimiser les requêtes.

Mes recherches sur le net ayant été infructueuses, si quelqu'un passant par là, et voyant de quoi je parle, pouvait apporter une aide quelconque, je lui en serait reconnaissant. Je ne sais pas pourquoi je bloque là dessus ..

C'est pour un site d'association assez spécifique, et je suis bénévole.

Merci !

[Benjamin Delespierre]

Hello.

Ce que tu demande n'est pas bien complexe et à mon avis c'est pour ça qu'on ne trouvera pas grand chose sur le net. De plus, la gestion des options c'est assez spécifique à une application.

Si tu cherches à faire quelque chose d'assez générique voici comment tu pourrais procéder:

• Avec MySQL (le plus simple)
• Avec du XML (le plus sexy !)
• Avec un fichier INI (le plus rapide)

Avec MySQL:

Les tables:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb` ;
 
-- -----------------------------------------------------
-- Table `mydb`.`option_categories`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`option_categories` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NOT NULL ,
  `comment` VARCHAR(255) NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `mydb`.`options`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`options` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NOT NULL ,
  `value` TEXT NOT NULL ,
  `type` ENUM('STRING','NUMBER','ARRAY','BOOLEAN') NOT NULL DEFAULT 'STRING' ,
  `comment` VARCHAR(255) NULL ,
  `option_categories_id` INT NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_options_option_categories` (`option_categories_id` ASC) ,
  CONSTRAINT `fk_options_option_categories`
    FOREIGN KEY (`option_categories_id` )
    REFERENCES `mydb`.`option_categories` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
 
 
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Avantages:

• relativement simple à mettre en place
• possibilité de ne récupérer que les options qui nous intéressent

Inconvénients:

• accès base systématiques
• peu flexible

Avec XML:

Structure:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="utf-8"?>
<options>
    <group id="g1" name="group 1" comment="Commentaire 1" />
	<group id="g2" name="group 2" comment="Commentaire 2" />
	<group id="g3" name="group 3" comment="Commentaire 3" />
	<option id="o1" name="opt1" group-id="g1" data-type="string" comment="opt com 1">
		Valeur 1
	</option>
	<option id="o2" name="opt2" group-id="g1" data-type="int" comment="opt com 2">
        123
    </option>
	<option id="o3" name="opt3" group-id="g2" data-type="boolean" comment="opt com 3">
        true
    </option>
</options>

A parser avec DomDocument ou SimpleXML.

Avantages:

• très flexible
• pas d'accès base
• peut être directement transformé dans un autre format avec une XSLT

Inconvénient:

• Relativement complexe à manipuler (si on ne connait pas DOM)

Avec INI:

Structure:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
[groups]
group_1 = "Commentaire 1"
group_2 = "Commentaire 2"
group_3 = "Commentaire 3"
 
[options]
opt_1[name] = "Option 1"
opt_1[value] = "Valeur 1"
opt_1[type] = "string"
 
...

A parser avec parse_ini_file.

Avantages:

• pas d'accès base
• lecture très rapide
• très simple à manipuler

Inconvénients:

• difficile à mettre à jour de façon programmatique

Résumé
Chacune de ces méthode présente des avantages et inconvénients qu'on peut résumer ainsi:

• Si le nombre de lecture est plus important que le nombre d’écritures (voire pas d'écriture du tout) la solution INI sera parfaite
• Si on a autant besoin de lectures que d'écritures, la solution XML sera tout à fait adaptée
• Si on fait plus d'écritures que de lectures, la solution MySQL est plus adaptée

Tu l'auras compris, ça va surtout dépendre de tes besoins. S'il s'agit de lire des paramètres statiques, fais-le en INI. En revanche, si l'application doit régulièrement mettre à jour les données (au travers d'un back end par exemple) alors envisage du MySQL ou du XML.

[Heirem]

Merci de ta réponse, mais j'aurais du me douter qu'en écrivant à 3 h du mat cette nuit je n'allais pas être assez exhaustif ni explicite dans ma question.

Oui oui une gestion d'options c'est assez simple et spécifique à une application. Cependant tu me présente des structure de stockage alors que comme je le disais le problème est beaucoup plus du coté PHP. Et je pensais avoir insisté sur le problème de la quantité d'options.. c'est à dire plusieurs centaines probablement ...

Je m'explique. L'objectif visé est de pouvoir disposer de deux fonctions :
- set_Option(<Nom de l'option>,<Groupe>,<Valeur>)
Pour attribuer un groupe et une valeur à l'option.
- get_Option(<Nom de l'option>,<Valeur (optionnel)>)
Pour lire la valeur d'une option donnée, et si elle n'existe pas elle est créée automatiquement avec comme valeur la donnée passé en paramètre et mise dans un groupe d'option par défaut.

La donnée de l'option doit pouvoir être de N'IMPORTE QUEL TYPE. Et n'être stockée que dans une seule et même rubrique. Par de rubrique par type de donnée en sorte. Et une seule table qui s'appelle elle-même avec une relation mère-fils pour les regroupements.

De plus quand je parlais d'optimisation et de performances, une mise en cache de l'option à la première lecture éviterait de trop nombreux appels à la base de données.

Oui XML c'est sexy. Mais une fille avant de penser à être sexy doit d'abord apprendre à marcher avec des talons hauts ...

Et oui toi aussi tu as tout compris, il faut que cela passe par du MySQL. J'ai tellement bossé avec les fichiers .INI par le passé que j'aurai bien aimé .. mais non ! Là faut pas ..

J'ai déjà résolu des problèmes bien plus complexes que celui-ci ... mais sur ces options je dois avoir un mauvais karma .. je sais pas pourquoi je bloque lamentablement ... parait que ça arrive à nous tous au moins une fois ..

[Benjamin Delespierre]

Oui oui une gestion d'options c'est assez simple et spécifique à une application. Cependant tu me présente des structure de stockage alors que comme je le disais le problème est beaucoup plus du coté PHP.

Y'a pas de problème avec l'implémentation en PHP des trois propositions proposées, y'a que des solutions.

La donnée de l'option doit pouvoir être de N'IMPORTE QUEL TYPE. Et n'être stockée que dans une seule et même rubrique. Par de rubrique par type de donnée en sorte.

C'est bien le cas avec les 3 solutions proposées.

Et une seule table qui s'appelle elle-même avec une relation mère-fils pour les regroupements.

C'est une mauvaise idée, c'est beaucoup plus complexe à gérer qu'une relation aussi simple que celle que je t'ai proposé.

De plus quand je parlais d'optimisation et de performances, une mise en cache de l'option à la première lecture éviterait de trop nombreux appels à la base de données.

Ce qui ne t'évitera pas de devoir recréer le cache entre deux requêtes HTTP.

Oui XML c'est sexy. Mais une fille avant de penser à être sexy doit d'abord apprendre à marcher avec des talons hauts ...

Je n'ai aucune idée de ton niveau mais franchement, XML c'est plus simple qu'il n'y paraît.

Et oui toi aussi tu as tout compris, il faut que cela passe par du MySQL. J'ai tellement bossé avec les fichiers .INI par le passé que j'aurai bien aimé .. mais non ! Là faut pas ..

Au contraire c'est possible mais c'est pas simple. J'ai d'ailleurs créé une classe capable de lecture/écriture sur un fichier INI.

A toi de jouer.