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