Concernant les artworks, avez-vous bien le droit de les distribuer comme ça ? Je me rappelle du site http://www.fankit-nintendo.fr/ qui proposait tout un tas d'artworks HQ des jeux Nintendo récents : il a été fermé alors que propulsé par Nintendo...
Pour parler un peu plus technique :
Vous obliger à utiliser un CMS comme Drupal est un bon dommage car ça ne va pas super bien avec le concept du site, mais vous avez quand même réussi à faire un truc pas mal avec. Je pense cela dit que si le projet est amené à être continué dans un cadre non-scolaire, il faudra penser à faire mettre vraiment les mains dans le cambouis et le faire évoluer vers une vraie techno du Web ^^
Attention pour le référencement, votre balise <title> est toute nulle et vous n'avez pas de balise <description>.
Le fichier SQL est évidement le gros intérêt du service, mais du coup également le truc avec le plus d'améliorations à faire
Déjà, pourquoi une seule table ? Ca va vite devenir un gros truc bien lourd et peu exploitable avec toutes les données de Pokémon.
Il faudrait au gros minimum une table pokemons qui contiendra les infos des créatures et une table types avec les types "Eau", "Feu". Une table especes pourrait être intéressante, il me semble bien que la relation Espèce - Pokémon n'est pas du 1-1, mais du N-1.
Idem pour les conditions d'évolutions : avoir un unique champ Condition_d_evolution en VARCHAR(255) est bien trop lourd est inexploitable pour une application qui veut faire autre chose que de l'affichage de données.
Le champ entity_id n'est pas en auto-increment ! Pourquoi ?
Il me semble d'ailleurs inutile, il aurait été plus judicieux de mettre la clé primaire sur le numéro national, non ? ^^
Autre chose ennuyeuse concernant l'internationalisation : à part les noms, toutes les données sont en français (y compris les noms des champs !), rendant le tout franchement très peu exploitable, ce qui est bien dommage vu le travail déjà mis en place.
Le truc le plus embêtant, en fait, c'est les conventions de nommage : une structure de base de données, c'est comme des conventions de code : personne n'a les mêmes. Tu trouveras forcément des gens qui n'adoptent pas vos conventions SQL (j'en fais partie
) : s'ils veulent utiliser vos données pour leur application ils devront travailler avec des convention qui ne leur conviennent pas, du coup ça ne le fait pas.Il ne faut pas oublier non plus que la plupart des projets récents utilisent des ORM utilisant des formats de données très précis. Enfin, dernier point, tout le monde n'utilisent pas les mêmes moteurs SQL, ni même SQL tout court : quid de MongoDB et autres technos NoSQL ?
Un jeu vidéo en C++ par exemple n'utilisera pas forcément une BDD MySQL ^^
Ca rend donc votre BDD encore moins utilisable malheureusement.
Je ne sais pas si tu connais le concept des API, mais je pense que c'est là que votre projet aurait tout son intérêt : vous continuerez à remplir votre BDD MySQL actuelle avec vos conventions à vous et vous exposerez ces données sur le Web à travers une simple API.
On peut imaginer par exemple que ce lien :
http://www.porygondex.com/api/pokemons/25/
Afficherait un JSON contenant toutes les données anglaises de Pikachu.
(en lieu est place de l'erreur 500 qui n'est pas normale : pourquoi on n'a pas une 404 ici ?
)http://www.porygondex.com/api/pokemons/fire/
Afficherait un JSON contenant des données minimales des Pokémons du type Feu.
Etc.
De la même façon que Facebook expose les données publiques des utilisateurs. Ainsi, pour les données du fondateur du réseau social :
https://graph.facebook.com/4/
Twitter a également sa propre API. Ainsi, pour récupérer les derniers Tweets concernant Nintendo :
https://api.twitter.com/1.1/search/twee ... q=nintendo
(bon, Twitter a mis en place un système d'authentification en oAuth pour pouvoir utiliser son API donc cliquer sur ce lien ne donnera pas grand chose : cela dit, pour un système comme le votre ça peut être une idée ce genre de protection afin de vous éviter une trop grande consommation de ressources !)
Mario Universalis a d'ailleurs sa propre pseudo-API (toute nulle, je devrais la refaire...) pour une meilleure gestion interne des cartes :
http://mariouniversalis.no-ip.org/cards/api.php?id=1
Enfin bref, je pense vraiment que la mise ne place d'une API sera une sacrée force dans votre projet, car utilisable partout, par tout le monde, et avec les conventions que vous voulez. Il faudra juste écrire une doc expliquant comment manipuler cette API ^^
Bon courage en tout cas, c'est un projet vraiment chouette : s'il continue d'évoluer ça pourrait être une référence pour les développeurs fans de Pokémons : monter sa propre base de données Pokémons est souvent un facteur décourageant pour un tel projet comme tu l'expliques si bien. Cela dit, il faut donc s'assurer que la seule base publique soit la plus optimisée et pratique possible
