Xhoromag 4 - Présentation de la base de données et des critères appliqués aux AVH

[Skarn]

Je ne vois toujours pas pourquoi tu t'embêtes à mettre toutes les informations propres aux séries dans le même tableau que les avh. Quel intérêt de devoir copier-coller 42 fois la description générale de la série Paix aux anges ?

Pour le reste, c'est bon.

que c'était compliqué parce que c'était toi qui m'avait demandé 36 mini-bdd

J'ai changé d'avis. Errare humanum est.

[Caïthness]

Je ne vois toujours pas pourquoi tu t'embêtes à mettre toutes les informations propres aux séries dans le même tableau que les avh. Quel intérêt de devoir copier-coller 42 fois la description générale de la série Paix aux anges ?

Je vois que Monsieur a survolé mon post et l'exemple de la BdD .
Quand tu donnes un travail à plusieurs personnes pour un même résultat (l'idéal à l'arrivée), simplifie à mort. Evite les multiples sources (dans ton dernier cas, 3 onglets), simplifie à mort (donc 1 onglet), facilite la logique de remplissage (Série en premier), etc...
De plus, la série n'est pas recopiées 120 fois, puisque les AVH d'une même séri sont empilées ensemble l'une derrière l'autre.
Je régénérerai les 2 tables initiales AVH/Série après vérification.

[Skarn]

Je viens de mettre à jour le schéma de la base de données sur la Dropbox (v5). Je ne mets pas d'image cette fois-ci, car cela commence vraiment à ressembler à un pentacle d'invocations de grands anciens. J'ai ajouté la gestion des informations suivantes :

• On peut maintenant associer à une avh plusieurs types de fichiers : l'aventure elle-même (dans différents formats) évidemment, soit des "extra" (soluce, mise en bouche de quelques dizaines de paragraphes, bêtisier), eux aussi dans différents formats.
  
• Un fichier peut également être associé à une série plutôt qu'à une avh particulière, comme les tables de hasard pour une série de LS-like.
  
• Au niveau des permissions, un membre peut, si besoin est, maintenant maintenir à jour des informations d'aventures qu'il n'a pas écrites, de séries auxquelles il n'a pas participé, voire des fiches d'auteurs disparus.
  
• En contrepartie du point précédent, un membre peut aussi réclamer un compte auteur géré par un autre (cas d'un revenant par exemple).
  
• Possibilité d'ajouter un commentaire supplémentaire à la licence, propre à chaque aventure. L'occasion de caser les précautions d'usage pour les aventures tirées d'œuvres existantes ("Tous les personnages de CSS sont la propriété de C..."), ou reprenant des images "trouvées sur le net".
  

[Skarn]

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 :


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.
    
• 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.

[tholdur]

Ca pourrait faire une bonne AVH, la création de Xho4.
Avec des énigmes insolubles pour les non initiés.
Du genre celle de Lortag l'ancien dans la cité de Kharé. "Le créateur de la base de donnée vous présente plusieurs schémas correctifs afin de compléter la base de donnée. Il a visiblement quelques doutes, et pourtant l'un d'eux s'inscrit d'une manière parfaitement logique dans l'ensemble. Lequel?"

Tout ça pour dire que je comprends à peu près la logique des titres sur fond bleu et des liens entre eux, mais pas vraiment le reste qui est sur fond blanc. Mais bon après tout ce n'est pas mon taf. Bon courage à Skarn!

[Alendir]

Ah oui le fameux GIT.
Apparemment sans être inscrit on a accès aux fichiers en lecture (heureusement pas en écriture).

Cette semaine j'ai partiels, ensuite on pourra se faire un tuto par skype (ça pourrait être intelligent de le faire en trio : skarn, shadow et moi, comme ça d'une pierre deux coups non ? Après faut trouver des horaires communs...).

[Skarn]

Ah oui le fameux GIT.
Apparemment sans être inscrit on a accès aux fichiers en lecture (heureusement pas en écriture).

Git, c'est le logiciel. Github, le site/serveur le plus utilisé. Et, à moins de payer, tes répertoires sont publics, mais cela ne me dérange pas (on n'a rien à cacher). J'ai commencé à coder, sur les fonctionnalités de gestion des membres et de leurs permissions, vu que c'est une partie pénible mais indispensable. Encore quelques bricoles à ajouter/vérifier, et je te livre ta liste de tâches longues comme le bras.

[Netwak]

Première remarque sur ta base de donnée Skarn, la table member devrait être divisé en deux : User et Person.

Pouquoi ? Imagine un auteur anglais, tu veux pouvoir le mettre dans la table authorship. Actuellement, tu seras obliglé de créer un member pour lui alors même qu'il ne viendras peut-être jamais sur le site. Pouvoir mettre un login et un password à NULL n'est pas une bonne idée.

Donc :
User (Account, Member) => Tous ce qui attrait au données du site.
Person (Author) =>Tous ce qui attrait à la personne, les données du profil.

1 User possedera toujours exactement 1 person.
1 Person possédera de 0 à 1 User

[Skarn]

Dans les faits, c'est ce que j'avais proposé dans une version précédente de la base de données (oui, il faudrait faire un peu de ménage dans les sujets).

Cependant, je m'étais rétracté, car on se retrouvait avec une jonction supplémentaire quasiment systèmatique, et un duplicata inutile d'informations : l'utilisateur Oiseau aura généralement le même pseudonyme que l'auteur Oiseau.

Je n'aime pas non plus accorder la possibilité à un champ "password" d'être vide. Cependant, on peut esquiver ce problème en le remplissant le cas échéant avec une valeur aléatoire. Pour le login, pour l'instant c'est la même chose que le pseudo, bien que j'hésite à les séparer pour plus de flexibilité. Et le mail est celui de son membre responsable. Étrangement, c'est ce dernier point qui m'embête le plus, car il m'oblige à renoncer à l'index UNIQUE sur la colonne "mail".

Les membres "fantômes", les auteurs non-inscrits, auront bien évidemment un statut correspondant ('unregistered') avec autant de droits qu'un invité (ou qu'un membre banni).

[Netwak]

Par rapport à la jointure automatique, ce n'est pas forcément vrai. On peut utiliser le fait qu'il y ait deux tables pour vraiment séparer la partie Compte de la partie Auteur.

Par exemple, pour tout ce qui authentification, on n'a pas besoin de la table auteur. Pour les présenter les auteurs on n'a pas besoin des informations sur le compte. La condition de cela étant un login différent du nickname (ou pseudo de l'auteur).

De plus, avec l'utilisation du cache la jointure ne fait pas forcément perdre en performance. De toutes façon, je doute que les performances soit un objectif avec Xhoromag 4.0.

[Skarn]

C'est vrai que lors de l'authentification, on n'a besoin que des informations de connexions, et lors de l'affichage des aventures/articles, que de celles du profil de l'auteur. Et on peut charger en session une partie des informations si besoin est.

Cela nous ferait donc deux tables :

User
-------
id
login
password
mail
user_status_id
confirmation_key
last_visit_time

Person
--------
nickname
description
fullname
description
user_id*
create_time
update_time
main

Où user_id est l'identifiant du responsable de ce compte, et main un booléen ayant pour valeur vrai s'il s'agit du compte principal (son vrai profil).

L'idée me plaît bien. D'autres remarques Netwak ? La version la plus à jour du schéma est sur le Github, sous le nom schema_vX.mwb.

De toutes façon, je doute que les performances soit un objectif avec Xhoromag 4.0.

Enfin, même si ce ne sera pas un critère bloquant, il est toujours plus agréable de faire les choses au mieux, ne serait-ce que pour notre confort personnel.

EDIT : petite modification de structure

[Netwak]

Par rapport aux main, je suis pas sûr de l'utilité de posséder plusieurs profil. A voir.

Pour les tables en rapport avec les avh, j'ai une proposition. Que la table avh délègue un maximum à la table avh_revision. En clair, toutes les avh possèdent aux moins une révision (la 1 en général) qui correspondra au départ au projet. Ensuite toutes les renseignements sont récupéré sur ces avh révisions. Cela nous permet par exemple de sortir des révisions en bêtas (value < 1) et simplifie la table avh. Une aventure terminé (complete) corresponde dans ce cas à une aventure qui possède au moins une révision > 1 (on peut rajouter un tag automatique pour faciliter les recherches).

On aura une table comme ça :

avh
----------
id
title
url_key
description
user_id
collection_id
volume_number
free
licence_id
licence_comment
(à voir si on ajoute un champ current_revision_id)

avh_revision
-------------
id
avh_id
avh_status_id (planifié (planned), en cours (working), sortie (release) ou annulé (canceled))
value
description (meilleur que revision_reason, plus clair et plus standard)
section_count
create_time
release_time (si le statu de la révision est planned ou working, alors c'est la date prévue de sortie, sinon c'est la date de changement de statut (annulation ou sortie)

Ensuite on a quelques colonnes pour l'avancement de la révision. A voir si on ne les met pas dans une autre table pour gérer un historique.
current_section_count
advancement (dans le cas ou l'auteur veut gérer sa propre façon de calculer l'avancement de sa révision)
update_message (c'est pouvoir afficher un message lorsque l'auteur change l'avancement)

EDIT: J'ai rajouté les champs en rapport avec la licence que j'avais oublié.

[Netwak]

Quelque petits trucs sur les tables fichiers :
- Rajoute une colonne download_count. Ça peut être sympa de conserver cette infos (et ne coûte pas grand chose). On aura peut-être des surprises.
- Le champ free n'a pas forcément d’utilité pour les avh_files. Si quelqu'un ne veut pas que son aventure soit accessible, il enlève le fichier, c'est tout.
- Tu as fait une petite erreur : key à la place d'url_key.
- Pour les file_format, tu peux ajouter un champ directory (ou path) pour ajouter la possibilité de ranger les fichiers par type.
- Je ne vois pas l'utilité d'un url_key pour les formats. Il y a pas forcément d'utilité à créer une page spécialement pour chaque format de fichier. (à moins que cela correspond à ce que j'ai proposé avant)
- Pourquoi name et filename ? Je ne vois pas de raison particulière de faire cette différence.
- Créer une table image, on pourra y mettre pêle-mêle : les avatars, la couverture des avh et les logos des séries.

image
------------
id
type_image_id (avatar, logo, couverture)
file_format_id
url_key
width
height

[Skarn]

Par rapport aux main, je suis pas sûr de l'utilité de posséder plusieurs profil. A voir.

Bah, chaque utilisateur a son profil propre, celui associé à son compte, mais également les profils des auteurs dont il s'occupe. Par exemple, Salla aurait son propre profil, mais aussi celui d'Andrew Wright à gérer.

Pour la table avh, j'admets qu'il y a un certain nettoyage à faire, avec un tas de booléens que l'on peut remplacer par des tags.

Cependant, je pense qu'il faudrait conserver avh_status_id et section_count dans cette table, car ce sont des informations qui vont beaucoup servir, et ce serait bête de devoir fouiller dans les révisions à chaque fois pour les faire remonter. En mettant un TRIGGER sur tout INSERT dans avh_revision, on peut gérer cela automatiquement sans avoir à faire de requêtes supplémentaires.

Je serais aussi pour marquer dans le marbre directement dans la table avh la date "release_time" de première sortie de l'aventure (premier passage à "release" et premier ajout d'un fichier), histoire que des petits malins ne changent pas une virgule tous les deux jours pour rester sur la page d'accueil en tant que dernière avh sortie.

avh_revision
-------------
id
avh_id
avh_status_id (planifié (planned), en cours (working), sortie (release) ou annulé (canceled))
value
description (meilleur que revision_reason, plus clair et plus standard)
section_count
create_time
release_time (si le statut de la révision est planned ou working, alors c'est la date prévue de sortie, sinon c'est la date de changement de statut (annulation ou sortie)
current_section_count
advancement (dans le cas ou l'auteur veut gérer sa propre façon de calculer l'avancement de sa révision)
update_message (c'est pouvoir afficher un message lorsque l'auteur change l'avancement)

Inclure un champ dans avh_revision pour la date de sortie prévue est une bonne idée. Il faudrait également un statut supplémentaire "refactoring" (corrections en cours). Même si, informatiquement parlant, ce sera la même chose que "working", avec une nouvelle date de sortie et tout, ce n'est pas tout à fait le même sens pour l'utilisateur du site ou l'auteur lui-même.

Un truc que je n'ai pas compris : quelle est la différence entre description et update_message ? Dans les deux cas, il s'agit d'un texte qu'écrit l'auteur pour expliquer la raison de cette mise à jour et que l'on affiche. De même, section_count=planned_section_count=nombre de paragraphes prévus ?

D'accord pour laisser l'auteur entrer son avancement "à la main" s'il le désire.

Rajoute une colonne download_count. Ça peut être sympa de conserver cette infos (et ne coûte pas grand chose). On aura peut-être des surprises.

J'ai même été plus violent, avec ma table avh_view, prévue pour enregistrer pour chaque lecture d'aventure l'IP, et éventuellement l'id de l'utilisateur. Bien évidemment, ces informations ne seraient pas divulguées publiquement, elles serviraient juste à limiter les doublons (lecteurs uniques).

Le champ free n'a pas forcément d’utilité pour les avh_files. Si quelqu'un ne veut pas que son aventure soit accessible, il enlève le fichier, c'est tout.

C'était au sens "gratuit" ici.

- Pour les file_format, tu peux ajouter un champ directory (ou path) pour ajouter la possibilité de ranger les fichiers par type.
- Je ne vois pas l'utilité d'un url_key pour les formats. Il y a pas forcément d'utilité à créer une page spécialement pour chaque format de fichier. (à moins que cela correspond à ce que j'ai proposé avant)

Cela devait être cela, mais je dois avouer que cela devait être une mauvaise idée car je ne m'en souviens plus. Va pour un champ "directory", c'est tout de même plus explicite.

- Pourquoi name et filename ? Je ne vois pas de raison particulière de faire cette différence.
- Créer une table image, on pourra y mettre pêle-mêle : les avatars, la couverture des avh et les logos des séries.
image
------------
id
type_image_id (avatar, logo, couverture)
file_format_id
url_key
width
height

Filename = nom du fichier, name = nom à l'affichage sur le site. Je les ai séparé après m'être rappelé cela. Et aussi, pour des raisons esthétiques, l'entrée "Table de hasard" pouvant correspondre au fichier au nom unique "Neige d'Automne - Table de hasard", concaténé à l'extension ".pdf".

Une table image est une bonne idée. Je pense que l'on peut virer le type_image_id au profit d'une image_id dans les tables correspondantes (avh, collection et profile), et mettre un bête name (UNIQUE) à la place de url_key et file_format_id. Cela nous permettrait de placer toutes nos images dans un méga-dossier images/ (ou un user/images/, pour les différencier des images du site non-issues des utilisateurs), sans avoir besoin de réfléchir. Il manque un champ "alt" par contre.

[Netwak]

Pour les profils d'auteur non membre, je voyais plutôt une gestion publique. Une fois l'auteur rentré tout le monde (ou seulement des modérateurs) peuvent modifier les infos. Je ne vois pas de raison que celui qui a enregistré le profil est plus de droit que les autres.

Mon idée par rapport aux tables avh été la simplification à l’extrême. Éviter qu'un même champ ne soit présent dans deux tables différentes. Maintenant oui on peut recopier un certain nombre de champ afin d'être performant (maintenant ce n'est pas mon approche préféré). On sera peut-être obligé à chaque fois de faire une jointure pour la révision courante. Donc peut-être que l'on gagne rien.

Pour la release_time, je pense que l'on pourra ajouter automatiquement un tag PROJET et l’enlevé lors de la première release. Ce qui permet d'introduire mon idée de tag automatique. Impossible à ajouter manuellement sauf pour les admin/modérateurs. Modifié uniquement par le serveur. Il suffit de rajouter un booléen automatic dans la table Tag.

Pour refactoring, est ce que ce serai plus normal qu'un auteur fasse dans ce cas là une nouvelle version ?

La différence entre description et update_message c'est que update_message est juste un message cours lors d'un changement de l'avancement (genre je viens d'ajouter 33 paragraphes). La description décrit le changement global de la révision.

Ta classe avh_view je ne l'avais pas vue, elle n'est présente sur aucun diagramme. Par contre je pense qu'il faudra prend en compte plus de cas et pas uniquement le nombre de vue de la page avh. Pour ça on a deux choix : plusieurs tables, soit une table générale. Pour les fichiers, je pense pas que compter les visiteurs uniques soit utile.

Pour le champ gratuit dans la table avh_file, on ne compte pas faire une option de e-commerce non ? Donc je vois pas l'utilité.

Pour les fichiers, le nom de fichier n'a pas d'intérêt. Pour la simple bonne raison que l'on utilisera url_key pour ça. Sinon cela fait double usage.

Pour les images, le alt sera certainement un truc à faire automatiquement. Et je pense que si on garde qu'un seul champ, le mieux et de garder url_key. Le but de type_image_id et de différencier les logos, des couvertures, des avatars, ...

EDIT : Correction de quelque petites fautes.