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

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