MySQL supporte les transactions, elles sont simplement "désactivées" par défaut:
http://dev.mysql.com/doc/mysql/fr/commit.html
http://dev.mysql.com/doc/mysql/fr/transactional-commands.html

;)

Ben, moi je vois que ça permet de s'affranchir d'un sacré paquet de code et de refiler le bébé à la base de données ... même si je n'ai pas souvent utilisé autre chose que MySQL.

Après, est-ce qu'un choix comme PostgreSQL est bon en terme de rapidité d'exécution et compagnie ?

on peut gérer les tours de jeu de différentes manières:
- tout est calculé chaque jour à telle heure
- le joueur voit son tour "faire le plein" toutes les X heures

on peut s'en tirer avec mysql (suffit de voir le nombre de jeux qui l'utilisent ) mais le kit triggers, procedures stockees et compagnie est très interessant (confort de programmation).

A+

PAscal

Ce n'est même pas que j'ai envie de développer un tel système de jeux, c'est juste que je me demande qu'est-ce qui serait le plus adapté à ce genre d'architecture.

Je pense notament à la gestion d'un tour de jeu :
Si un tour à lieu toutes les x minutes, les joueurs définissent leurs actions pendant le temps mort et les actions sont effectuées quand le compteur de temps tombe à zéro (une tâche cron en fait). D'où, ma question sur les commit et les rollbacks ...

Bonjour,

Du code PHP/SQL optimisé, avec un bon système de cache, influera beaucoup plus que la base de données. A mon avis, choisis la base de données que tu connais le mieux, et concentres toi plutôt sur le code.

vive la machine a sous oué :wink:

Bonjour à tous,

J'ai remarqué qu'en ce moment, les jeux en PHP sont très à la mode : il n'y a qu'à regarder les forums PHP traitant de recrutement, la plupart des annonces sont sur ce theme, et généralement, tout ça se fait de manière bénévole.

Ce que je vois aussi, c'est que la plupart des projets de ce type utilisent MySQL, car généralement livrée avec une offre d'hébergement PHP, mais je m'interroge sur le choix de cette base de données.

Prenons un exemple simple: un jeu de stratégie.
Dans ce jeu, nous aurons une ou plusieurs cartes avec chaque carte découpée en cases. Il y aura aussi des unités, qui auront chacune des caractéristiques propres par défaut (points de déplacement, points de vie, points d'attaque, points de défense, ...), mais chaque unité en jeu aura aussi ses caractéristiques à elle. Notez aussi là dessus qu'il faut gérer les différents joueurs ... bref, il y a beaucoup de données à traiter, avec plusieurs jointures entre les différentes tables présentes.

:arrow: Etant donné que la majorité des jeux écrits en PHP se font au tour par tour et que le traitement des données du jeu devraient se faire "par lot", pensez vous que MySQL soit adapté à ce genre d'application ?
:arrow: Vu le type d'application, pensez vous qu'une base de données plus "évoluée" gérant les vues, triggers, procédures stockées, commit et rollback (comme PostgreSQL) soit plus adapté à ce genre de traitement ?

Bref, qu'en pensez vous ?