Xhoromag 4 - Base de données

[Alendir]

Voilà une ébauche de BDD. Oiseau m'a envoyé ses idées de BDD, ce qui a pas mal rempli la table AVH.

Le premier schéma (MCD) représente les tables de bases et leurs liaisons logiques :




Le deuxième (MPD) représente les tables telles qu'elles seront dans la BDD (il y en a de nouvelles, certaines liaisons se transformant en tables) :




Commentaires :
-Table AVH
*disponible vaut false si l'AVH n'est pas disponible en téléchargement.
*numVolume vaut 0 si n'appartient pas à une série
*nbRevision initialisée à 0


Évidemment, il manque sans doute des attributs à certaines des tables. Cette première version est un encouragement au brain storming.

---

Pour la table Membre, j'hésite à créer un attribut nbAVH. J'aurais tendance à penser que c'est inutile vu qu'on peut le déduire de la table AVH, mais ça veut dire qu'il faudrait faire des calculs à l'ordi à chaque fois qu'on demande l'affichage des caractéristiques d'un membre.

[Caïthness]

J'ai fait un début de BDD sur un fichier excel

[Shadow]

Hello,
Voici quelques petites remarques qui pourront peut-être aider :

- faut-il rajouter un champ 'mot de passe' dans Membre ? (je vois qu'il y a une dateConnexion, ce qui me fait donc penser qu'il faut un pseudo/mot de passe pour se connecter au site).
Peut-être faudrait-il ajouter aussi l'adresse email, même si on ne l'affiche pas sur le site.

- peut-être pourrait-on utiliser des tables à part pour le genre et l'univers, peut-être aussi pour les règles ?
Leurs valeurs sont en nombre limité (par exemple, pour le genre : medFan, fantastique, ...) et peuvent servir pour de nombreux AVH.
Cela permettrait aussi de faciliter les filtres de recherche sur ces différents attributs et de les centraliser :
on pourrait par exemple créer facilement une liste déroulante avec l'ensemble des genres possibles avec un "select id,nom from Genre;"

- En regardant le site Xhoromag, je vois aussi les attributs "Stats", "Linéarité", "Combats", doit-on les rajouter ?
Pareil, il serait peut-être plus judicieux de les mettre dans des tables spécifiques.


Pour ta question sur l'attribut "nbAVH", il nous faudrait quelqu'un qui s'y connait bien en sql :
Est-il possible de sélectionner des informations de la table Membre et de faire un count des AVH correspondant au Membre en une seule requête ?
Si cela est possible, je pense qu'il n'est pas nécessaire d'avoir ce "nbAVH" : en effet, le nombre d'enregistrements de la base de données n'étant pas énorme, le temps d'exécution de la requête ne devrait pas être très long.
Dans le cas contraire, cet attribut deviendrait bien utile car il permet d'éviter une requête supplémentaire.
Dans ce cas, je pense qu'il pourrait être utile d'ajouter un "nbAVH" aussi dans Serie si l'on souhaite afficher le nombre de tomes dans la fiche descriptive de la série.

Edit :
il est en effet possible de connaitre les informations du membre ainsi que son nombre d'AVH en une seule requête, je viens de faire joujou avec un pgSQL, et voici la tête de la requête :
select m.pseudo, m.nomComplet, count(a.titre) from membre as m
inner join AVH as a on m.idMembre=a.idMembre
group by m.pseudo, m.nomComplet;

En conclusion, je pense qu'il est inutile d'avoir un attribut supplémentaire "nbAVH"... En même temps, le group by peut devenir costaud si on affiche pas mal d'infos ... Ah .. le dilemme ...


Edit :
Pour la transcription des liaisons [Membre-AVH] et [AVH-Série] dans la BDD, je ne suis pas sûre qu'elles demandent de nouvelles tables :
Je pense que rajouter un idSerie et un idMembre dans la table AVH suffirait : en effet, l'AVH ne peut être rattaché qu'à un seul membre et une seule série.

[Skarn]

Je suppose que la vraie base de données sera en anglais après que l'on se soit mis d'accord sur des conventions de nommage hein ?

Cela étant dit, mes remarques :

Ne devrait-on pas diviser auteur et utilisateur ? En effet, particulièrement dans le cas d'une aventure traduite, il arrive que des membres postent des aventures pour des auteurs non inscrits. Et lorsque l'on fera la migration, il va falloir remettre des aventures de membres disparus, qui ne pourront donc s'en charger eux-mêmes.

Les connexions entre membres et aventures sont en (0,n) et (1,n) : plusieurs auteurs peuvent avoir écrit une aventure. En fait, la table de jonction nécessaire pourrait même contenir le rôle du membre : auteur, traducteur, illustrateur etc.

Pour les aventures, j'attends les résultats de Caïthness et Fitz pour me prononcer, mais l'on aura très certainement des tables à part pour le genre, l'univers etc.

À la fois pour les utilisateurs et les aventures, il y aura probablement des tables de "flicage", contenant l'historique des connexions/mises à jour. Ensuite, pour des raisons d'optimisation des accès en base, il sera quand même utile de dédoubler la date de la toute dernière dans la table principale.

Je pense qu'il va aussi falloir une table séparée pour les formes sous laquelle l'aventure sera disponible (PDF, en ligne, en papier).

Pour ta question sur l'attribut "nbAVH", il nous faudrait quelqu'un qui s'y connait bien en sql Smile :
Est-il possible de sélectionner des informations de la table Membre et de faire un count des AVH correspondant au Membre en une seule requête ?
Si cela est possible, je pense qu'il n'est pas nécessaire d'avoir ce "nbAVH" : en effet, le nombre d'enregistrements de la base de données n'étant pas énorme, le temps d'exécution de la requête ne devrait pas être très long.

Oui, et oui. De la même, le nombre de révisions n'est pas utile.

EDIT : une image valant mieux qu'un long discours

Les tables avh et user sont volontairement tronquées. Ici, on enregistre la série (c'est bien collection en anglais ?), le classement au Yaz par année, la licence (© par défaut), les différents types de support (avh_format -> pdf, en ligne, papier), les différents types d'auteurs (author_role -> écrivain, illustrateur, traducteur, chef de projet etc.), et également de compter le nombre de lectures. L'enregistrement de l'IP et de l'identifiant utilisateur serve juste à établir des statistiques plus justes, en éliminant les doublons. Ces valeurs ne seront pas accessibles depuis le site. Le nombre de lectures, et leur évolution dans le temps, sera une donnée uniquement accessible à l'auteur.