Je m’interroge sur le meilleur schéma de données à adopter pour un système de base photo, le but étant de stocker les informations récupérées à partir des champs IPTC/XMP de chaque image :
- En-tête
- Légende
- Photographe
- Ville
- Département
- Pays
- Mots-clés
- …
Pour les mots clés, j’ai d’emblée choisi de recourir à une table dédiée keywords et une table de jointure :
keywords (id, name)
keywordsToPicture (keyword_id, picture_id)Me reste donc une table Picture telle que :
Picture (id, header, caption, photographer, city, state, country)Ça sent la redondance !
Si j’applique les bonnes pratiques de conception de BDD, je décompose Picture en cinq tables comme suit :
Picture (id, header, caption, photographer_id, city_id)
Photographer (id, name)
City (id, name, state_id)
State (id, nom, country_id)
Country (id, name)
L’indexation est facilitée, et je supprime toute redondance dans la table Picture qui sera, de loin, la plus grosse de la BDD (à minima plusieurs milliers d’enregistrements). Mais je trouve la granulosité un peu élevée. Sachant qu’une requête sur une image retourne toutes les informations associées, cela fait quatre jointures par requête.
Merci de me faire part de vos remarques, avis ou conseils sur la solution envisagée.
# Mise en cache
Posté par yellowiscool . Évalué à 1.
Si sqlite ne doit pas avoir de gestion du cache, je ne sais pas du tout pour un sgbd plus gros, tel que postgresql. À voir donc.
Envoyé depuis mon lapin.
# Premature optimization…
Posté par thibault jouannic . Évalué à 2.
Pour un bon SGBD, gérer quelques milliers d'enregistrements (surtout de cette taille), c'est de la rigolade. Si tu n'as aucune raison objective de décomposer tes tables, rends toi un service, choisit la solution la plus simple et la plus facile à maintenir.
Essayer de résoudre des problèmes qui n'existent pas (encore) est un des meilleurs moyens pour pondre du code pourri.
# le design d'abord !
Posté par gaaaaaAab . Évalué à 2.
et alors ?
Si tu penses que ça peut poser des problèmes de perf, tu as peut-être raison, mais c'est beaucoup trop tôt pour s'en soucier. Privilégie la propreté du design de la DB, et implémente les requêtes qui vont taper dedans.
Si un jour tu rencontres un problème de perf, il sera temps de réfléchir à la façon d'y faire face ... mais pas maintenant.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
sinon, une remarque en passant, il peut y avoir plusieurs villes portant le même nom dans un même pays.
[^] # Re: le design d'abord !
Posté par balzane . Évalué à 2.
il peut y avoir plusieurs villes portant le même nom dans un même pays
L'écueil me semble contournable en fixant dans la table City une contrainte d'unicité sur la paire name, state_id : avec ça je dois pouvoir gérer (presque) tous les homonymes.
[^] # Re: le design d'abord !
Posté par NeoX . Évalué à 3.
ou un ID unique fournit par la base, et ajouter un champs "code postal"
quand la personne recherche par ville, tu lui demandes alors de preciser laquelle des X villes il veut.
cf le site viamichelin.fr par exemple
# table de tags
Posté par zx81 . Évalué à 2.
-tag_id
-tag_name
-tag_value
et ensuite avoir une table de jointure avec les photos.
Le truc un peu embêtant, c'est le type de la valeur (char? num ? ...) mais ça devrait être contournable avec un champ tag_type+plusieurs valeurs et une fonction qui renvoie le bon champ (ou un trigger qui met à jour les autres types dans la mesure où les convertions sont possibles).
Sinon, ok avec les autres commentaires, ne dénormalise que si tu y es obligé et dans tous les cas fais des vues pour masquer la structure table/jointures en dessous :-)
Que prévois-tu d'utiliser comme sgbdr ?
[^] # Re: table de tags
Posté par balzane . Évalué à 2.
Comme l'appli attaque la BDD via un ORM (Doctrine), le choix n'est pas critique à ce stade.
Ta proposition de table de tags ne me semble utilisable que pour les mots clefs, les autres champs ont, selon le standard IPTC, des tailles très variables (de mémoire, 2000 caractères pour la légende).
En revanche, la remarque sur l'utilisation de vues pour masquer la structure sous-jacente est très pertinente :-)
# et sinon Kphotoalbum
Posté par GG (site web personnel) . Évalué à 2.
le logiciel Kphotoalbum fait exactement ce que tu veux.
Le seul problème avec Kphotoalbum, c'est qu'il fonctionne qu'avec sqlite, du coup, à partir de 30000 photos/vidéo l'enregistrement (ou la mise à jour de la base de donnée) est un peu long sur une vieille bécane à 1GHz.
Il permet d'exporter dans divers formats, et d'importer les fichiers Kim (photos+données), il permet aussi d'envoyer par e-mail les documents sélectionnés avec en option une réduction de taille, et créé autant de messages que nécessaire pour ne pas dépasser le seuil de poids par message.
A l'installation, Kphotoalbum est livré avec une démo :) et un film, donc tu sauras vite si ça te va ou non.
Éventuellement, tu pourrais t'en inspirer, ou faire ce qui manque pour que Kphotoalbum soit capable de se servir d'une autre base de donnée.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.