nombre illimité de photos et base de données

[fabrice88]

Bonjour,
actuellement lorsque je veus enregistrer des photos vers ma base de données dans ma table je definit des champs photo - photo2 - photo3 - photo4 ...
le probleme avec cette methode c'est qu'on est limité au nombre de photos defini par le nombre de champs photos.

Je recherche donc une autre solution pour le cas ou je souhaieterai mettre un nombre ilimité de photos.
Suis-je obligé de créé xxxxxx champs ? ou existe il une autre solution ?

 

[spout]

Avec 2 tables:
1° les enregistrements: "posts"
id
title
...

2° les photos, avec une relation: "posts_photos"
id
post_id (id de l'enregistrement)
filename
...

 

[dop20vt]

Ou bien un champ photos contenant les urls des différentes photos séparées par un masque !!

Exemple :
url_photo1:::::url_photo2:::::url_photox

 

[UsagiYojimbo]

La solution de spout est la plus propre a mon avis.

 

[dop20vt]

La solution de spout est la plus propre a mon avis.

Nianiania

 

[UsagiYojimbo]

La solution de spout est la plus propre a mon avis.

Nianiania

Quitte à stocker plusieurs infos dans un même champ, je préfère de toutes façons les sérialiser proprement plutôt que d'utiliser un séparateur quelconque.

Et globalement, si ce sont des données finales (c'est à dire sur lesquelles il n'y a pas de traitement complémentaires à effectuer), ça peut être intéressant, mais si comme dans le cas présent il peut y avoir besoin de faire des liaisons avec des fichiers physiquement présent, ou des jointures avec d'autres tables, je choisirais la solution de spout.

 

[dop20vt]

Pas faux pour le serialize() !! C'est plus propre

 

[skyll]

La solution de spout est la plus propre a mon avis.

tout à fait d'accord :mrgreen:
sinon dans la famille pas propre, tu peut inserer tes photos entière dans un type blob, avec séparateur :lol:
(y faut pas hein !! c'étais une blague :mrgreen: )

 

[UsagiYojimbo]

A une époque je faisais ça. C'est vrai que ça peut avoir ses avantages, mais ça augmenter de manière exponentielle le poids de la BDD.

 

[skyll]

A une époque je faisais ça. C'est vrai que ça peut avoir ses avantages, mais ça augmenter de manière exponentielle le poids de la BDD.

mais quand même pas toutes les images avec des séparateurs dans le mêmem blob :wink:
sinon, oui, ca peut avoir des avantage :mrgreen:

 

[UsagiYojimbo]

mais quand même pas toutes les images avec des séparateurs dans le même blob :wink:

Nan, of course.

 

[fabrice88]

Ok merci j'ai opté pour la version 2 tables.

 

[extremenet]

pourquoi 1 table et non 1 ??? moi j'utiliserai 1 seul table.

 

[UsagiYojimbo]

pourquoi 1 table et non 1 ??? moi j'utiliserai 1 seul table.

Et tu aurais quel modèle de données dans ce cas ?

Avoir une table secondaire permet de rattacher un nombre de photos différent à chaque article sans pour autant modifier la base de données.

 

[extremenet]

oui mais une table avec
id_image
titre_image
lien_image

suffit pas ?

 

[Zecat]

A une époque je faisais ça. C'est vrai que ça peut avoir ses avantages, mais ça augmenter de manière exponentielle le poids de la BDD.

mais quand même pas toutes les images avec des séparateurs dans le mêmem blob :wink:
sinon, oui, ca peut avoir des avantage :mrgreen:

Là c'est plus explode mais explose :mrgreen:

 

[UsagiYojimbo]

oui mais une table avec
id_image
titre_image
lien_image

suffit pas ?

Si il y a des infos à stocker autour de l'ensemble des images (descriptif de galerie, titre, etc) ce n'est pas la meilleure solution non