Où mettre les données constantes ?

[php_addict]

bonjour

on a tous un tas de données persistantes

ex: $ma_variable_pour_tout_le_site = 1345 ;

comment les gérées vous quand vous n'êtes pas en POO?

- avec un simple include ?
- avec require ?
- variables de sessions (bof...)

y a t il d'autres facon de procéder ?

bonne fin de journée à vous tous.

[keke]

J'ai une table paramêtre ( id_parametre, nom_variable, valeur_1, valeur_2)

Et je requête quand j'en ai besoin.
Souvent, les variables sont mise en variable de session pour les moins sensibles. D'autres sont recherchées à tout moment (genre la variable qui indique si le serveur est en cours de mise à jour ...)

kéké

[Argorate]

Salut,
Rien de plus facile, effectivement, tel un fichier de config, tu mets tes variables dans un fichier php que tu te contentes d'include

L'avantage c'est que lorsque ces données sont fixes, c'est plus rapide de travaillé en mémoire (dans des variables) que de les mettre en BDD pour ensuite allez faire des requetes... (on perd un temps fou pour aucun gain d'autre part)

Moi j'ai des tableaux entier que j'inclue comme ça. Ca m'a grandement amélioré le temps d'execution...
(et le temps de créer un tableau c'est pas plus long ni pénible que de faire plein d'insert...)

[My Hotel]

Personnellemet, pour la config par défaut du site genre news_par_page, j'enregistre ça dans un ini, que je parse avec parse_ini_file. C'est rapide, et assez pratique
Et j'ai une classe qui s'occupe de me renvoyer la config par défaut, sauf si l'utilisateur l'a modifiée (genre augmentation du nombre de messages/page) alors ça renvoie la modifiée.
La config personnalisée est stockée elle en BBD (logique).
Le ini, c'est l'avantage de la BDD, ou presque (facilement modifiable sans toucher au code) sans les inconvénients des tableaux (longs à charger si trop gros, pour modifier faut aller taper du PHP...) tout en restant rapide à l'exécution.

Et pour les autres données genre celle du jeu, là je stocke en BBD (liste des unités, bâtiments...), avec cache si besoin est.

Bye

[Sephi-Chan]

Au boulot, les sites qu'on développait pour des clients avaient généralement une table "configuration_items" dans laquelle on stockait ce genre de chose. Cette table contenait les colonnes "domain", "key" et "value". Le domaine sert à établir des espaces de noms afin de ne pas confondre les per_page pour les utilisateurs et ceux des articles, par exemple.

Et on définissait une méthode statique d'accès rapide dans notre modèle :

class ConfigurationItem < ActiveRecord::Base

  

  def self.get(domain, key)

    value = find_first_by_domain_and_key(domain, key)

    

    raise MissingConfigurationItemError if value.nil?

    value

  end



end



# Et dans le code :

players_per_universe = ConfigurationItem.get(:universe, :players_per_universe)

Ainsi, quand une clé est manquante (pas bieeeen !!!), on lance une exception (que le front contrôleur gère pour rendre une vue explicative, bien entendu).

C'est facile à administrer (pour le client), facile à maintenir (pas besoin de toucher au code source), sûr (on lance une exception s'il manque quelque chose), rapide (une base est excessivement rapide quand elle recherche un élément précis et met en cache la requête). Bref, du code robuste et professionnel.

Après, c'est sûr que c'est pas adapté à tout : on ne peut pas stocker les informations de connexion à la base, par exemple. Pour ces dernières, Rails utilise un fichier YAML.


Sephi-Chan

[php_addict]

merci pour vos avis...

- je ne vais pas retenir la solution de la base de données, je n'y met que les données non persistantes...

- j'ai un doute quand au parseur de .ini car si un petit malin tombe sur l'url ca ne me plait pas...

je pesne que je vais retenir l'include de varaibles ou variables tableau dans un fichier php ( car meme au cas ou un petit malin tombe sur l'url du fichier il ne pourra pas le voir? je me trompe ou pas?

merci de vos conseils

[Sephi-Chan]

Je pense que tu fais l'amalgame entre données constantes et données persistantes.

Si tu utilises un fichier PHP, effectivement il sera interprété avant d'être servi par le serveur (sauf si le serveur Web n'est pas configuré pour interpréter les scripts PHP), donc il n'y aura aucun retour pour le client.

Concernant les fichiers ini, il suffit de les mettre en dehors du DocumentRoot si tu veux en protéger l'accès. Comme tout fichier censé être utilisé en interne par l'application.


Sephi-Chan

[Anthor]

Y'en a encore qui mette l'application dans public_html ?

[php_addict]

Je pense que tu fais l'amalgame entre données constantes et données persistantes.

oups...certainement, et quelle est la différence? (mon projet est très bien avancé mais il faut que je m'achete quand meme un bouquin sur le php/SQL et autres )

[Sephi-Chan]

Persistante s'oppose à volatile. Une donnée volatile n'existe qu'un court laps de temps (par exemple, une variable (même globale) définie dans un script fini n'existera que pendant quelques instant : la donnée sera perdue à la fin du script.

A l'inverse, pour faire persister une donnée, on la stockera en base de données, dans un fichier, etc.

- je ne vais pas retenir la solution de la base de données, je n'y met que les données non persistantes...

La base de données ne contient que des données persistantes.


Sephi-Chan