Bonjour à tous,

Je suis en train de coder mon projet, mais je rencontre une difficulté à la conception de ma base de données.
Je vais vous énoncer mon problème, et détailler la solution que j'ai retenue:

Énoncé

Un client possède un site qui gère de nombreuses images et stock les paramètres de l'image en BDD. Il veut mettre en place un système de votes sur le principe "top/flop". Le client veut aussi garder un trace de tous les votes, pour élaborer des statistiques et dans un soucis de sécurité. Cependant, il a un espace alloué à sa BDD limité à 10Mo, et comme il attend de très nombreuses images (environ 17 millions), il souhaite un système rapide et qui demande le moins de moins d'espace de stockage possible.

Solution

Je pense faire 3 tables, une table images, une table membres et une table votes.
Les images seront identifiées par leur id et leur hash MD5 (pour des raisons techniques) et auront des champs tels que leurs codes hexadécimal (il en a 2 par images) et la date de création.
les membres seront identifiés par un id, et auront des champs comme la date d'inscription, la date de dernière activité et si le membre est daltonien.
Les votes vaudront soit 1 (top) soit 0 (flop). Il seront insérés en base avec comme informations l'id de l'image et l'id du membres, ainsi que la date du vote.



Je voudrais savoir si ce modèle est juste et compréhensible, et ce qui peut être amélioré. Je voudrais aussi des astuces sur les indexes à placer pour avoir une plus grande rapidité lors de jointures par exemple (lors des statistiques).

Je vous remercie d'avance,

Ealon

Citation : Ealon

Je voudrais savoir si ce modèle est juste et compréhensible, et ce qui peut être amélioré.

- Si un membre ne peut voter qu'une seule fois par image, la colonne id de la table vote est inutile. La clé primaire est composée de deux colonnes (qui sont elles même des clés étrangères).

- On préfère ne pas donner des noms de table au pluriel, une table est sensé être un ensemble (de ligne), c'est du sngulier.

- Essayes d'améliorer ta convention de nommage des colonnes.
Met un préfix, par exemple.
Les clé étrangères doivent avoir le même noms que les clé primaires quelles références, ça permet entre autre d'utiliser des jointures naturelles.

Citation : Ealon

Je voudrais aussi des astuces sur les indexes à placer pour avoir une plus grande rapidité lors de jointures par exemple (lors des statistiques).

A priori, il n'y a rien à faire, les index générés automatiquement derrière les PK/FK devraient suffire. Est-ce que tu as déjà une idées des requêtes qui vont être les plus utilisées ?

Merci pour ta réponse Cintre Sournois,
je vais m'éfforcer de répondre à tes demandes.

Citation : Cintre Sournois

Si un membre ne peut voter qu'une seule fois par image, la colonne id de la table vote est inutile. La clé primaire est composée de deux colonnes (qui sont elles même des clés étrangères).

Alors le membre peut voter plusieurs fois pour la meme image. En fait, les images sont générées aléatoirement, ce qui fait qu'un membre peut attendre 2 images comme 17 000 images afin de retomber sur une pour laquelle il a déjà voté.

Citation : Cintre Sournois

On préfère ne pas donner des noms de table au pluriel, une table est sensé être un ensemble (de ligne), c'est du sngulier.

Je ne savais pas, merci bien

Citation : Cintre Sournois

Essayes d'améliorer ta convention de nommage des colonnes.
Met un préfix, par exemple.
Les clé étrangères doivent avoir le même noms que les clé primaires quelles références, ça permet entre autre d'utiliser des jointures naturelles.

Peux tu expliquer un peu plus cette notion de FK et PK stp?

Citation : Cintre Sournois

A priori, il n'y a rien à faire, les index générés automatiquement derrière les PK/FK devraient suffire. Est-ce que tu as déjà une idées des requêtes qui vont être les plus utilisées ?

Pour le moment, je n'ai pas vraiment de requêtes complexes en tête, mais je pense que des requêtes pour compter le nombre de votes (tops et flops) pour telle image ainsi qu'une requête pour compter le nombre de votes par images/membres sera mise en place.

Je suis allé un peu vite, FK (Foreign Key) et PK (Primary Key), pour clé étrangère et clé primaire.

Regarde ici :
http://www.developpez.net/forums/d8230 [...] /#post4724879

Citation : Ealon

Cependant, il a un espace alloué à sa BDD limité à 10Mo, et comme il attend de très nombreuses images (environ 17 millions), il souhaite un système rapide et qui demande le moins de moins d'espace de stockage possible.

Ce qui te laisse pas loin d'un demi octet par image pour enregistrer les informations dans la base de donnée (source, photographe, copyright, licence, dates, résolutions, mots-clés, etc).

Donc la première chose à faire est de convaincre le client d'arrêter d'être neuneu, et supprimer cette restriction idiote.

> le membre peut voter plusieurs fois pour la meme image

Je suppose que dans ce cas le nouveau vote écrase l'ancien, sinon on peut faire facilement un script qui vote 1000 fois pour l'image qu'on préfère.

Sinon, le schéma, c'est classique, je seconde cintre sournois, cependant :

- la table des votes sera en InnoDB et aura comme clé primaire (image_id, user_id) ; sachant qu'InnoDB organise la table sur disque en fonction de la clé primaire je pense qu'il est avantageux de le mettre dans cet ordre. Utilise INSERT .. ON DUPLICATE KEY UPDATE. Il faut aussi un index sur (user_id), sinon lister les votes d'un utilisateur sera lent, de même que la suppression (ON DELETE CASCADE) des votes d'un utilisateur.

- Pour pouvoir trier les images par le nombre de votes, il est obligatoire (au niveau des performances) de dénormaliser un peu et donc de matérialiser le score de votes dans ta table images et de mettre un index dessus. Tu peux compter les tops, les flops, les deux, ou top-flop, comme tu veux, mais il faut le mettre. Tu tiens ça à jour avec un trigger sur la table des votes qui modifie les compteurs de l'image en question dans la table images.