j'imagine oui.

et là ce n'est qu'une ébauche de ce que je veux faire, mais j'ai 10 fois plus de choses à intégrer dans mon schéma, beaucoup de colonnes en plus etc.

je vais m'amuser à faire fonctionner tout cela en PHP =)

d'ailleurs, je code toujours "à l'ancienne" (sans IDE ou framework particulier), sous vi avec les fonctions de base (mysql_connect, mysql_fetch_assoc & co)

recommendez vous d'utiliser un framework particulier (du genre zend ou autre) ? pour la portabilité/compatibilité du code source ou autre raison ? (j'ai regardé zend mais ça a l'air vachement Lourd xd)

recommendez vous d'utiliser un framework particulier

Pas forcément, tu peux très bien utiliser un framework que tu a fait toi même

si tu développe tous seul tu peux faire comme tu veux, c'est pas un soucis

Si tu souhaite être aider (maintenant ou plus tard) c'est mieux si tu utilise quelque chose de structuré, pas forcément de la poo mais structuré de façon à ce que tout le monde utilise les mêmes composants pour les mêmes choses.

La l'avantage de la poo c'est que la modélisation de la chose est faite, tu peux répartir simplement et rapidement les composants entre les différents dev.

Un framework va t'aider dans le sens où tu n'auras pas a développer la mécanique de l'application web (le MVC) tu n'aura a faire que les vue et les controleurs.

tu peux t'en passer et t'orienter vers un dev perso qui fera la gestion des vue et des controleurs.

Coté code oublie l'extension mysql elle est déprécié et plus maintenue, oriente toi vers l'extension mysqli (en général y a juste le i à ajouter dans les fonctions

tu peux aussi te tourner vers PDO, coté abstraction du SGBD, sauf si tu code des requêtes avec des fonctions propriétaires, tu feras rapidement de l'universel (bon un peux utopique mais réalisable )

@+

merci bcp, je n'étais pas au courant pour le mysql"i", c'est bon à savoir

sinon j'ai regardé PDO ça a l'air intéressant, notamment car la base risque de devoir être portable sur de l'Oracle.
après, les types sont différents sur les bases, donc il est clair que les requêtes seront différentes, mais si déjà les appels (fonctions) sont les mêmes, c'est un temps considérable de gagné.

actuellement au bureau j'ai développé un intranet sur MySQL, et on me demande de porter tout sur Oracle, donc il va falloir que je regarder comment convertir l'intégralité de mon code 'à l'ancienne' de mysql vers oracle, et à priori c'est pas gagné :p
donc à l'avenir dans mes projets, j'aimerais éviter ça =) ou tout faire pour réduire le travail évidemment.

quant à la POO, j'y réfléchis justement, ça peut être intéressant d'utiliser les classes pour toute la partie personnage/item & compagnie, faut que je regarde comment interfacer ça avec la base de données, mais je pense que le code sera + lisible en plus de ça, ça ne peut être que bénéfique j'espère.

merci

Pour ce qui est du portage mysql oracle, le problème ne vient pas du fait qu'il y ai des types différents (pas de text, utilisation de varchar2 et non varchar, l'auto increment c'est mysql donc à remplacer par une série et un. Tricher nèfle insert etc). Le problème vient des choses "propriétaire" des sgbd. Par exemple mysql implémente limit, qui 'existe pas chez oracle. Mais en fouillant bien tu trouvera une clause similaire (rows quelque chose).
Et c'est la que la portabilité est réduite car généralement les requêtes sont écrite en dur dans le code.
Pour éviter cela tu peux utilisé un ORM qui va te créer tes requêtes en fonction du sgbd

Sinon dans ton cas je te conseillerais de créer des vue contenant le code "proprietaire" et d'utiliser ces vues à partir de php. Comme ça pas de soucis les requêtes sont toujours les mêmes

Côté insertion pas d'insert multiple pour oracle, c'est pas vraiment gênant, update / delete c'est pareil.

Le plus gros travail c'est de mettre en forme les données (un bon éditeur de texte qui cherche et remplace tout ).

Pour la poo, cela te permet d'avoir ton modèle dans le code "comme" dans la base ça te permet de bien suivre ce que tu fait.
Après il y a la compartimentation du code et ça t'evite la tentation de créer une classe item qui va les affichées? Les modifier etc. Une telle classe existes mais pas sous ce nom (itemdao par exemple) un item c'est Les fameux pour dont j'ai parlé avant.

Avant de te lancer je te conseil de regarder quelque tuto sur la modélisation d'application. Et sur la poo (par exemple les design pattern très utile).

Enfin bref poo oui c'est bon, mais seulement si tu ne te perd pas sinon ça va être le merdier et tu va t'y perdre (perso j'ai du mal à me retrouver sur les premiers projets perso sans aucune modélisation )

@+