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

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