Fichier ou BDD???

[Holy]

Personnellement j'utilise les deux, de manière relativement équilibrée ^^

Et même pour des accès en écriture J'ai développé une petite bibli perso qui permet facilement de rendre l'accès en écriture d'un fichier exclusif tant qu'un script travaille dessus, et à mettre en "pause" un autre script qui aurait besoin du fichier

Toute ma map par exemple se trouve dans un fichier, protéger par un htaccess, et ça fonctionne sans aucun problème

Je pense que, de fait, si on développe de bons outils, l'utilisation de fichiers peut être un excellent complément à l'utilisation de la BDD de manière à désengorger celle-ci

Voici une rapide liste de ce que j'ai dans un fichier:
- Toutes les caractéristiques de mes unités, bâtiments et capitales.
- Toute ma carte est intégralement contenue dans un fichier (accès en écriture multiples (tout changement sur la map) et en lecture forcément)
- Forcément mes news, mais ça c'est pas très originale ^^ (accès en écriture une seule fois, lecture pour le reste)
- Les combats qui ont été générés (accès en écriture une seule fois, lecture pour le reste)

Mine de rien, ça me permet d'éviter une série de requêtes pour ma BDD.

C'est pas super conventionnel, mais ça marche. En tout cas, ce qui est clair et net, c'est que pour toutes les données sensibles et les données qui sont amenées à être traitées plus largement par des tris, etc. la bdd est largement plus indiquée.

[Ruz]

...
Perso, j'ai été tout un temps adepte du full BDD

Puis, à force de lire ce forum, j'ai commencé à mettre des fichiers pour éviter des requêtes répétitives sur des données qui changent pas/peu. A noter deux détails:
1) les fichiers sont des copies de données de la bdd (=> changement en bdd doit déboucher sur une régénération du fichier correspondant => modification via le panneau d'administration du site only)
2) les fichiers sont des fichiers .php contenant une/plusieurs variable(s) utilisable(s) directement (un peu plus volumineux)
=> Si affichage du fichier : rien
=> Fichier inutilisable sans connaitre la(les) variable(s) présentes

par exemple, la page d'accueil de mon site ne nécessite aucune requête bdd (mais affiche des news, des stats, des données générales (nbre inscrits), etc...) juste des fichiers inclus à l'appel. Si le fichier n'est pas inclus, une requête se fait pour compenser ET régénérer le fichier problématique.

[Allwise]

J'pense que ça dépend de ce qu'on a besoin de stocker et des besoins d'organisation / classement des données, que les deux sont complémentaires, mais que chaque méthode a ses propres domaines d'application.
On devrait utiliser les fichiers lorsque :
- On a besoin de lire des données uniquement, et de les lire toutes, sans faire de tri.
- On a besoin d'écrire des données, d'y accéder. Mais pas besoin de modifier les données déjà présentes dans le fichier, je pense aux fichiers logs par exemple.

Dans les autres cas, où on doit pouvoir accéder à une partie des données seulement, les modifier, les lier entre elles... Je pense que l'utilisation d'une BDD est quasi incontournable. Je dis quasi parce que je pense au XML qui offre pas mal de possibilités.


Sinon, le système dont tu parles, Ruz, n'est ni plus ni moins un système de cache

[Ruz]

Sinon, le système dont tu parles, Ruz, n'est ni plus ni moins un système de cache

T'as tout compris ^^

[keke]

Evite au maximum le fichier ...

je me demande si cette règle est pertinente ?

Vu que la question est d'ordre générale (je rappelle la question : Fichier ou BDD ?) je pense pas qu'il faille s'appesantir sur tous les cas particuliers.
Après tout, les Bases de données sont des fichiers plats traité par des scripts avec une gestion d'accès concurentiels, de cache, etc ... mais ca reste du fichier ...

A partir du moment où la question n'est pas plus ciblée, je trouve ma réponse totalement pertinente. Je n'ai rien contre l'usage des fichiers, mais au mieux, ce qui peut être en base de donnée devrait aller en base de donnée...

La Carte qui n'évolue pas en fichier plat sera un frein le jour où justement on voudra la faire évoluer, la faire grandir, etc ...
Les caractéristiques des unités en fichier plat sera un frein le jour où l'on cherchera à équilibrer les forces via un script auto du marché.
Le mini-frame-perso pour traiter des fichiers plats à la sauce Base de donnée risque d'être un poil plus léger en terme de ressource ... mais cela n'a-t-il pas été une perte de temps à développer ?

Bref, ce sont des questions rhétoriques. Je demande pas de réponse à ces dernières questions. Ca illustre juste ma phrase d'origine.

kéké

[Anthor]

Evite au maximum le fichier ...

je me demande si cette règle est pertinente ?

Vu que la question est d'ordre générale (je rappelle la question : Fichier ou BDD ?) je pense pas qu'il faille s'appesantir sur tous les cas particuliers.
Après tout, les Bases de données sont des fichiers plats traité par des scripts avec une gestion d'accès concurentiels, de cache, etc ... mais ca reste du fichier ...

A partir du moment où la question n'est pas plus ciblée, je trouve ma réponse totalement pertinente. Je n'ai rien contre l'usage des fichiers, mais au mieux, ce qui peut être en base de donnée devrait aller en base de donnée...

La Carte qui n'évolue pas en fichier plat sera un frein le jour où justement on voudra la faire évoluer, la faire grandir, etc ...
Les caractéristiques des unités en fichier plat sera un frein le jour où l'on cherchera à équilibrer les forces via un script auto du marché.
Le mini-frame-perso pour traiter des fichiers plats à la sauce Base de donnée risque d'être un poil plus léger en terme de ressource ... mais cela n'a-t-il pas été une perte de temps à développer ?

Bref, ce sont des questions rhétoriques. Je demande pas de réponse à ces dernières questions. Ca illustre juste ma phrase d'origine.

kéké

Je doute toujours de la pertinence d'une telle réponse
Je n'ai aucun problème à éditer mes fichiers, et je ne passe pas plus de temps à créer ma classe, si classe il y a vu que les fonctions natives sont totalement pertinentes.

Je me souviens de cursus où les bases de données n'étaient pas étudiés au profit des fichiers, et ensuite étudiées à part.

[Argorate]

Cela dépend de quel données tu parles. Je pense qu'un jeu optimisé utilise les deux...

J'ai certaines données invariables que je met dans des fichiers (php, pas txt!) et le reste ça va en BDD... Tout dépend de ce que tu veux en faire. Pour te donner un exemple concret, mettre en BDD les infos et effets de chacune des météos que j'ai dans mon jeu serais totalement stupide.

Ces données ne changent plus (une fois la beta et l'équilibre trouvé bien sur). J'ai juste créé un tableau php, je l'inclus dans les pages adéquat et j'ai plus qu'a m'en servir direct dans mon code... C'est plus rapide et donc en l'occurrence mieux.
Cependant la majorité des données sont en BDD!

[wild-D]

la réponse pour moi la plus correcte à la question: "Fichier ou BDD ?", est "ça dépend" ^^
(la seule règle absolue est celle qui consiste à ce servir de ses neurones; plutot que d'éviter au max les fichiers ) (et si tu lis la question en entiez et pas juste le titre tu constatera que AxeMan2593 introduit lui-même la nuance de savoir ou se situe le juste équilibre entre les 2 )

- le principe de base est d'utiliser les outils qui ont été fait pour; pas besoin de réinventer la roue non plus hein; franchement entre un file_put_contents + var_export avec un include de l'autre coté; on code pas plus qu'à faire des requêtes sql surtout quand au final ta table comptera moins de 100 entrées de max 3 champs qui se résument à un entier et des varchar(30). (un SGBD c'est non seulement fait pour "CRUDer", mais ça l'ai avant tout pour le faire sur des "volume de données"). Je vois pas l'intérêt de promouvoir l'usage du 4x4 quand la bicyclette permet tout aussi bien d'aller du point A au point B.

- le 2e est de se sentir à l'aise avec la solution adoptée. Pourquoi se faire du mal à utiliser des jointure SQL; quand tu es plus à l'aise avec un foreach. Selon les situation l'une ou l'autre sera surement plus "performante/propre"; mais pourquoi se faire chier à utiliser une méthode qui nous convienne pas; faut aussi avoir du plaisir à développer son jeu ! (edit: bien sûr vaut mieux pas faire des mysql_query dans une boucle foreach on est d'accord )

[keke]

Je doute toujours de la pertinence d'une telle réponse

Anthor > Pour moi y'a pas photo, mais j'ai utilisé tous mes arguments en 2 messages ... j'vois pas ce que je peux dire de plus pour ^^. je creuse un peu ... et je m'arrêterais ensuite ^^

Le débat existe depuis longtemps :
en 2006 :
http://www.journaldunet.com/developpeur/...nees.shtml
où la réponse est : "ça dépend".

Cette réponse m'horripile, étant utilisable sur tous les débats en France (pardon Wild-D ^^). Au moins, dans cet article, nous ne traitons pas le cas spécifique nous concernant : le développement de jeux amateurs. 'P'tet ben qu'oui, P'tet ben que non', ce n'est pas une réponse en soit ... l'attendu de la question d'Axeman étant un choix et un avis personnel.

Les avantages du fichiers plats sont : une portabilité d'un système à un autre et une rapidité de traitement.
Les avantages de la base sont : un requêtage souple et performant et une évolution rapide du logiciel.

Quels est donc le besoin de manière globale au cas d'Axeman, la technologie à retenir ?

Après, lui signaler que l'autre option n'est cependant pas à jeter aux orties et peut apporter des satisfactions dans certains cas précis, c'est un plus ... Mais je pense pouvoir soutenir que dans 80% d'un projet sérieux où le problème se rencontre, une des solutions est tout de même plus pertinente...

Y'a t-il une personne qui a fait un jeu dont les logins des joueurs est marqué en fichier plat ? C'est une donnée qui est peu variable ... mais ça me semblerait bizarre de la stocker en fichier plat ...

A l'inverse un fichier log me semble justifié à bien égards ... De même je ne stockerais pas d'images en BDD ...

une Map ? pourquoi pas dans un cas ou dans l'autre ... A la rigueur si la carte est légère ... j'ai 20 cartes de 120*120 cases ... je n'aurais même pas pensé le faire en fichier plat sachant que de toutes les façons la BDD est utilisée ailleurs dans le projet.

Voilou de quoi alimenter le débat ^^. Je doute que Axeman souhaitait lancer un troll, mais il est vachement bien partit dis donc !

Y'a peut-être des débats sans fond qu'il faudrait nuancer selon le niveau de la personne qui pose la question ? C'est peut-être l'occasion de rajouter un petit tuto explicatif dans le Wiki, avec la description des méthodes employés par chacun des membres histoires de bien écraser le sujet et qu'on se chamaille plus dessus ^^.

kéké qui n'a plus du tout d'arguments ...

[Ter Rowan]

je rejoins (presque complètement) kéké

A la question "BDD ou fichier ?", je répondrais "par défaut BDD"

à savoir oui, dans certains cas c'est mieux d'utiliser des fichiers mais pour identifier ces cas, encore faut il savoir ce qu'est une BDD, l'avoir utiliser et identifier les cas où ce n'est pas forcément utile.

Perso, j'aurais tendance à classifier ainsi :

Dans une BDD obligatoirement :
les données qui varient tout le temps
les données où, en lecture , on utilise des filtres et sélections

Dans un fichier texte obligatoirement :
les données de configuration

Ca se discute :
les données d'une carte
les données de références : les types de XXX (constructions, unités....)


Dans mon cas, outre la configuration (accès aux bases, ce genre de trucs) j'ai introduit, très récemment, certaines actions de joueur (ex: ramasser , attaquer, se reposer, ...) pour la raison suivante : j'estime que ces actions sont peu nombreuses et quasi systématiques.
A contrario je ne mets pas en fichier mais uniquement en bdd les actions de type artisanat et autres jets de compétences particulières car un personnage utilisera rarement telle ou telle compétence (donc un filtre qui, à mon sens, justifie la bdd)

---

bon je viens d'être grillé par kéké, zut alors, mais cette fois complétement d accord avec son dernier post ^^