Albat => Ok pour base et table, je trouvais juste plus mes mots

naholyr => C'est tout a fait a ca que je pensais pour la dernière de tes reponses.

naholyr=> pour la gestion par fichier => j ai bassé mon forum (grand projet s il en est) sur l utilisatin de fihiers... Je suis donc, comme tu le di si bien, surement pas aussi "bon" qu'une bonne base SQL mais je pense que le gros du travail a déjà été fait et que donc je maitrise cette partie... (en tout cas plus que les base SQL)

Pour conclure je crois que je vais me diriger vers l utilisation de fichiers que je maitrise deja pas mal et puis me documenter un peu plus sur les bases MySQL pour pouvoir les incorporer efficamement dans mes futurs projets.

Je vous remercie pour votre aide

Shrito

Tu peux séparer les informations sur une même entité en "genre". Par exemple pour un carnet d'adresse, je vais devoir gérer: nom, prénom, téléphone, anniversaire, commentaires, numéro, rue, ville, code_postal, pays, email, fax, etc...

Tu vas pouvoir faire une seule table avec plein de colonnes, ou plusieurs tables selon les types de données à stocker, en attribuant un "identifiant" à chaque entrée. Par exemple:
Personnes(id, nom, prenom)
Contacts(id, téléphone, fax, email)
Adresses(id, numéro, rue, ville, code_postal, pays)
InformationsPersonnelles(id, anniversaire, commentaires)

Je ne suis pas sûr que ce soit un bon exemple de modélisation, mais ça peut être une façon d'optimiser. Au delà d'un certain nombre de colonnes pour une table (je dirais une vingtaine) il devient intéressant de "découper".

Je pense que pour simplifier je vais créer 5 ou 6 base plutot que une.

Attention : tu confonds "base" et "tables" !

Ceci dit pour cette dexuieme base je pourrais la réduire à une colonne en assemblant les différente valeurs de 27 colonnes avec implode...
du style val1_val2_val3_val_4 mais j aurais une length de plus de 200...
Pour ce qui est des colonnes elle ne serviront pas a la recherche je ferai une base a part pour calculer le classement soit une base de 1 colonne pour x enregistrement... se sera plus facile a classer

Ta description est plus proche de l'utilisation de fichiers que de la modélisation d'une base de données.
Je t'invite fortement à te documenter sur Merise et le SQL... (google est ton ami)

De façon très générale, un stockage par fichiers bien pensé et bien optimisé sera plus rapide qu'un stockage par base de données (puisque finalement une base de données ce n'est rien d'autre qu'un stockage par fichier, bien pensé et bien optimisé, avec une surcouche gérant les requêtes SQL et les connexions).

Mais tu devras faire un énorme travail d'optimisation, et de réécriture de toutes les procédures de mise à jour / insertion / recherche. C'est très très fastidieux.
Tu devras te faire confiance. Question sécurité & stabilité les bdd ont fait leur preuves, pas toi (ce n'est pas une critique hein, personne ne peut faire aussi bien en un projet qu'une équipe de développement avec des années d'expérience sur le même projet).

Au final, en pratique, une fois que tu auras développé ton module, il sera moins performant, moins flexible, et moins sûr qu'une base de données. Après c'est comme tu veux hein ^^

Salut,

J'ai réfléchi un peu depuis hier soir et ce n'est pas un mal...

Je pense que pour simplifier je vais créer 5 ou 6 base plutot que une.

Ainsi a chaque page consulté un utilisateur accédera a une base générique de x enregistrement (x = nb utilisateur) et de 6 colonnes + une seconde base de x enregistrement et au maximum 27 colonnes.

Ceci dit pour cette dexuieme base je pourrais la réduire à une colonne en assemblant les différente valeurs de 27 colonnes avec implode...

du style val1_val2_val3_val_4 mais j aurais une length de plus de 200...

Pour ce qui est des colonnes elle ne serviront pas a la recherche je ferai une base a part pour calculer le classement soit une base de 1 colonne pour x enregistrement... se sera plus facile a classer

Pour ce qui est de la frequence de modification, a priori se sera a chaque page consulté... si le joueur effectue une opération.

Voila si vous voulez plus d'info je suis dans le coin

Merci d avance

Utiliser une BDD MySQL avec une table de x enregistrement (x étant le nombre de joueurs inscrit) pour au moins 100 colonnes.

100 colonnes ?
Il y a peut-être un peu de modélisation à faire...

Il faudrait plus d'infos pour se faire une idée:

• sur ces 100 colonnes, combien sont nécessaires à chaque page ?
• est-ce que ces colonnes servent à effectuer des recherche parmi les joueurs ? (par exemple "tous les joueurs qui se sont connectés aujourd'hui")
• à quelle fréquence les enregistrements seront-ils modifiés ?
• tout information concernant la nature ou l'usage des données

Sauf que je ne compte pas acheter le serveur avant la mise en ligne réelle du site... Mais bon yen a certain qui doivent savoir si ce genre de chiffres sont tres élevés ou non...

hello,
d'aprés moi ça va dépendre des performances
de ton serveur MySQL, sur Free par exemple
il est trés lent.
tu peux facilement faire des tests de "performances"
sur ton serveur, en essayant les 2 méthodes
;o]

Bonjour a tous...

Voila je suis en train de développer un jeux on-line et je me pose la question quant au choix du stockage des données.

En fait j ai en tete deux possibilités :

1) Utiliser une BDD MySQL avec une table de x enregistrement (x étant le nombre de joueurs inscrit) pour au moins 100 colonnes.

Je me demande si le serveur ne va pas vite saturer car il n'est pas rare d'avoir en simultané pres de 200 joueurs...

2) La deuxièle possiblité est de stocker toutes ces informations sous formes de tableaux enregistrer dans un fichiers spécifique à chaques joueurs du type : nom_du_joueur.bdd

Voila merci de m'éclairer si vous le pouvez... Sachez que je compte héberger ce jeu sur un serveur payant dont le traffic est illimité...