Fin des vacances, il est temps de se retrousser les manches. Je suis repassé sur toute la base de données, et j'ai normalement tout nettoyé. Tout est dans la Dropbox, version 6. Comme le schéma global commence à être illisible, j'ai fait des sous-schémas par thème :
![[Image: 331886avhlisting.png]](http://img15.hostingpics.net/pics/331886avhlisting.png)
L'ensemble des tables nécessaires simplement pour afficher la liste des aventures. Et encore, en ne mettant pas les liens directs vers les pdf sur la page. Faut ce qui faut.
![[Image: 586958avhinformations.png]](http://img15.hostingpics.net/pics/586958avhinformations.png)
Et voilà tout ce dont on a besoin pour obtenir des informations détaillées. Faut encore ajouter trois tables pour avoir tous les fichiers, des fois que vous vouliez lire l'aventure. Ça en fait des données au final.
Plusieurs autres jolies images sont dans le fichier mwb.
D'un point de vue technique, il manque encore :
-Des clés uniques et des indexes à droite à gauche, particulièrement sur plusieurs colonnes à la fois.
-Les triggers MySQL, c'est-à-dire les scripts SQL qui mettent à jour automatiquement certaines valeurs en fonction de certaines actions sur la base. Par exemple, il en faudrait un pour que lorsqu'on ajoute un fichier, autre qu'une table de hasard, à une aventure, elle soit considérée comme disponible. Soit, en chinois, un TRIGGER sur un INSERT dans avh_file qui fait un UPDATE sur la table avh pour passer à true la valeur "available" dans avh si l'élément inséré n'a pas sa propre valeur "extra" à true.
Cependant, rien de bloquant, et rien qui ne puisse se faire au fil de l'eau au cours du développement. Je ne suis pas dupe, malgré le temps passé et le nombre de personnes motivées impliquées dans la conception de l'ensemble, il y aura sans doute encore quelques modifications structurelles à faire, mais normalement toute la charpenterie est là, et robuste.
Quelques remarques techniques :
Je vais de ce pas mourir, puis ressusciter et préparer une base Yii sous gestionnaire de versions, à partir de laquelle développeurs et graphistes (comprendre Alendir et Shadow) pourront s'amuser.
EDIT : hum, j'ai commencé à faire joujou avec du vrai code sql. Je viens de renommer toutes les colonnes key en url_key, car le premier est évidemment un mot-clé réservé. Et de rajouter des auto-increment oublié. Et... ça sent une v6.1 rapide tout ça.
EDIT 2 : j'ai mis à jour le répertoire Git. Dans les faits, je l'ai détruit et recréé pour de bonnes bases. Dorénavant, les évolutions de la base de données techniques (schémas, SQL) se feront à cet endroit, sinon cela deviendra vite ingérable. Pour les fichiers Excel, continuez à utiliser la Dropbox.
L'ensemble des tables nécessaires simplement pour afficher la liste des aventures. Et encore, en ne mettant pas les liens directs vers les pdf sur la page. Faut ce qui faut.
Et voilà tout ce dont on a besoin pour obtenir des informations détaillées. Faut encore ajouter trois tables pour avoir tous les fichiers, des fois que vous vouliez lire l'aventure. Ça en fait des données au final.
Plusieurs autres jolies images sont dans le fichier mwb.
D'un point de vue technique, il manque encore :
-Des clés uniques et des indexes à droite à gauche, particulièrement sur plusieurs colonnes à la fois.
-Les triggers MySQL, c'est-à-dire les scripts SQL qui mettent à jour automatiquement certaines valeurs en fonction de certaines actions sur la base. Par exemple, il en faudrait un pour que lorsqu'on ajoute un fichier, autre qu'une table de hasard, à une aventure, elle soit considérée comme disponible. Soit, en chinois, un TRIGGER sur un INSERT dans avh_file qui fait un UPDATE sur la table avh pour passer à true la valeur "available" dans avh si l'élément inséré n'a pas sa propre valeur "extra" à true.
Cependant, rien de bloquant, et rien qui ne puisse se faire au fil de l'eau au cours du développement. Je ne suis pas dupe, malgré le temps passé et le nombre de personnes motivées impliquées dans la conception de l'ensemble, il y aura sans doute encore quelques modifications structurelles à faire, mais normalement toute la charpenterie est là, et robuste.
Quelques remarques techniques :
- Pour la taille des champs, je me suis basé sur cette unique norme, ainsi que mon expérience personnelle. J'espère avoir été trop généreux que trop radin, cela pose généralement moins de problème. Pour information, le titre le plus long de tout Xho est Le Samouraï Galactique vs l’Ambassadeur Johanssen, soit 49 caractères.
- Je me suis imposé les règles de syntaxe suivantes :
- "code" représente une valeur pour le développeur, avec une clé unique. Elle ne sert que dans les tables sur lesquels il n'est possible d'écrire que via la machine, et peut être utilisé directement dans le code php, joyeusement écrit en dur. C'est typiquement indispensable à l'identification, pour différencier un administrateur d'un banni.
- "url_key" est une clé générée automatiquement à partir d'un autre champ (nom, pseudo, titre) et destinée à faire de jolies url, et uniquement à cela. Elle est là aussi unique par table, mais c'est le seul point commun avec la précédente.
- "code" représente une valeur pour le développeur, avec une clé unique. Elle ne sert que dans les tables sur lesquels il n'est possible d'écrire que via la machine, et peut être utilisé directement dans le code php, joyeusement écrit en dur. C'est typiquement indispensable à l'identification, pour différencier un administrateur d'un banni.
- J'ai laissé tombé l'idée du "Xhobot", pour éviter la confusion. Un article (= news) auto-généré n'a simplement plus de créateur, ni d'auteur ou de licence d'ailleurs.
- J'ai préféré faire des tables séparées mais similaires pour des besoins très proches, comme les commentaires d'articles et d'aventures, pour simplifier un peu la structure, surtout au niveau du code PHP qui est derrière. Par exemple, pour les commentaires, au lieu d'une unique classe Comment qui sert à tout et où on s'y perd, on aura les modèles AvhComment, ArticleComment, ainsi que leur papa Comment pour les fonctions communes (vive l'héritage). C'est plus simple, mieux organisé, et on n'y perd pas en performances, les deux tables n'étant normalement pas appelées sur la même page.
Je vais de ce pas mourir, puis ressusciter et préparer une base Yii sous gestionnaire de versions, à partir de laquelle développeurs et graphistes (comprendre Alendir et Shadow) pourront s'amuser.
EDIT : hum, j'ai commencé à faire joujou avec du vrai code sql. Je viens de renommer toutes les colonnes key en url_key, car le premier est évidemment un mot-clé réservé. Et de rajouter des auto-increment oublié. Et... ça sent une v6.1 rapide tout ça.
EDIT 2 : j'ai mis à jour le répertoire Git. Dans les faits, je l'ai détruit et recréé pour de bonnes bases. Dorénavant, les évolutions de la base de données techniques (schémas, SQL) se feront à cet endroit, sinon cela deviendra vite ingérable. Pour les fichiers Excel, continuez à utiliser la Dropbox.