Page 1 sur 2

Enregistrement d'un tableau

Posté : 20 juil. 2005, 10:37
par lulumOriss
Bonjour à tous,

Est-il possible d'enregistrer un tableau de valeurs dans un champs de ma BDD ?

Merci. lulu.

Posté : 20 juil. 2005, 10:46
par zeus
Non, pas directement car la structure de tableau PHP n'est pas reconnu par les BDD.

Par contre tu peux le linéariser pour en faire une chaine de caractères qui pourra être enregistrée

Mais je me permettrais de te faire remarquer que si tu doit enregistrer plusieurs valeurs dans un champs de ta BdD, c'est qu'il y a un problème de conception

Posté : 20 juil. 2005, 10:49
par raptor
Vive les associations :p

Posté : 20 juil. 2005, 11:23
par lulumOriss
Parlons-en des associations !
Je cherche justement (en tatonnant) à associer des enregistrements de tables différentes :

un (ou plusieurs) cuisinier avec ses propriétés possède une (ou plusieurs) recette avec ses propriétés, n'appartenant qu'à lui, qui contient un (ou plusieurs) ingrédient avec ses propriétés, utilisé par différentes recettes de différents clients.

J'avais posé la question ici, on m'avait alors proposé une table supplémentaire qui faisait l'association entre les recettes et les ingrédients.

Mais, je pensais qu'il était plus simple de créer les 3 tables et d'utiliser un champs dans la table cuisinier qui stocke, sous la forme de tableau, la liste des recettes qu'il possède et un champs dans la table recette qui stocke la liste des ingrédients de la recette.

Qu'en pensez-vous ?

Posté : 20 juil. 2005, 11:27
par ouckileou
J'avais posé la question ici, on m'avait alors proposé une table supplémentaire qui faisait l'association entre les recettes et les ingrédients.
Bonne idée
Mais, je pensais qu'il était plus simple de créer les 3 tables et d'utiliser un champs dans la table cuisinier qui stocke, sous la forme de tableau, la liste des recettes qu'il possède et un champs dans la table recette qui stocke la liste des ingrédients de la recette.

Qu'en pensez-vous ?
Mauvaise idée

ta solution parait plus simple car plus "légère" mais lorsque tu auras des requêtes de sélection à faire, de tri, de comptage, tu seras bien content d'avoir une relation ;)

Avec ton champ, lorsque tu rajoutes une recette à un cuisinier tu dois :
- récupérer le contenu du champ
- rajouter ta recette
- réinsérer

Si tu supprimes un recette, dont le numéro est situé au milieu de ta chaine, comment fais-tu ? compliqué encore une fois...

si 1 cuisinier peut posséder 0 à n recettes :
table cuisinier
table recette
relation entre les deux

;)

Posté : 20 juil. 2005, 11:30
par zeus
Je te dirais que toute personne qui a fait un peu de conception te conseillera la table intermédiaire

C'est vrai que c'est plus simple a stocker dans 1 champ, mais à manipuler, pardon

exemple :

tu as l'id d'un cuisinier et tu veux afficher toutes ses recettes.
TA METHODE:
- récupérer l'enregistrement du cuisinier
- modifier le champ qui contient les recettes afin de retrouver un tableau de valeurs
- interroger la table qui contient les recettes pour sélectionner celles dont les valeurs viennent d'être récupérées
- afficher ces valeurs

METHODE ASSOCIATION
- interroger la base de données avec une requete de type JOINTURE qui va associer la table cuisuinier, association et recette
- afficher les résultats

Pareil si tu veux enlever une recette à un cuisinier, dans ta méthode, il faut sortir la valeur, la transformer en tableau, supprimer la valeur, transformer en chaine et réinsérer dans la Bdb alors qu'avec les associations, il te suffit de supprimer la ligne qui associe le cuisinier avec la recette, directement en SQL

Posté : 20 juil. 2005, 11:31
par Daz
Conceptuellement la solution proposée ici est la meilleur.
Après si tu le sens mieux comme ça...

En fait si tu ne manipule pas de gros volume de données et si cette appli ne subit pas de trop forte charge il ne devrait pas y avoir de grosses différences

Daz

Posté : 20 juil. 2005, 11:43
par ouckileou
En fait si tu ne manipule pas de gros volume de données et si cette appli ne subit pas de trop forte charge il ne devrait pas y avoir de grosses différences
un peu quand même :lol:

franchement les manipulations sont incomparables, personnellement je n'hésiterai pas, il y a qu'à lire le comparatif de zeus pour voir que la relation simplifie tout

et puis en parlant de charges, on ne sait jamais, si le site devient très connu :lol:

en clair : relation, aucun débat possible ;)

Posté : 20 juil. 2005, 11:47
par zeus
Conceptuellement la solution proposée ici est la meilleur.
Après si tu le sens mieux comme ça...

En fait si tu ne manipule pas de gros volume de données et si cette appli ne subit pas de trop forte charge il ne devrait pas y avoir de grosses différences

Daz
Lol

Alors on va faire un test:
- chez toi tu crée une base de donnéesavec 1 champ ID et 1 champ val
tu met 1 seul enregistrement
- ensuite tu essaye de changer la valeur en l'extrayant, en la modifiant en PHP et en la réinsérant dans la base de données
- ensuite tu fait un UPDATE direct en SQL
- tu fait des mesures de temps pour chaque traitement

Mon exemple n'a aucun sens mais c'est la vulgarisation des différences entre les 2 solutions données plus haut

Tu sera d'accord avec moi que mon exemple ne manipule pas de millions d'enregistrements, et pourtant, la différence apparait déjà :wink:

Mais c'est vrai que si quelqu'un veut utiliser une pioche pour creuser un trou alors qu'il a acheté une pelleteuse, on peut pas le forcer :wink:

Posté : 20 juil. 2005, 11:56
par lulumOriss
Le problème, c'est que je n'avais ni pioche ni pelleteuse, alors je teste un peu tout. Quelqu'un a de la dynamite ? :wink:

Ok je reprends donc mes tables intermédiaires (on ne m'avait pas parlé de JOINTURE). Ça doit me donner 5 tables, si je ne me trompe : les 3 principales, une qui fait la relation cuisiniers/recettes et une qui fait la relation recettes/ingrédients.

Non ?

Posté : 20 juil. 2005, 11:57
par ouckileou
c'est ça ;)

Posté : 20 juil. 2005, 11:58
par zeus
Le problème, c'est que je n'avais ni pioche ni pelleteuse, alors je teste un peu tout. Quelqu'un a de la dynamite ? :wink:
Mais toi tu demande si il faut utiliser une pioche ou si tu peut utiliser la pelleteuse qui est à ta disposition :wink:

Posté : 20 juil. 2005, 12:00
par Daz
On est d'accord!

Posté : 20 juil. 2005, 12:01
par zeus
Attend, je viens de relire la description du sujet. Si un cuisinier à 0 à n recettes mais qu'une recette n'appartient qu'a 1 cuisinier, pas besoin d'associations.

Il suffit de stocker une clé étrangère vers le cuisinier dans ta table recette.
Par contre, vu qu'un ingrédient peut être utilisé dans plusieurs recettes, il faut que tu garde l'association recette/ingrédients

Posté : 20 juil. 2005, 12:29
par pjl
Mais, je pensais qu'il était plus simple de créer les 3 tables et d'utiliser un champs dans la table cuisinier qui stocke, sous la forme de tableau, la liste des recettes qu'il possède et un champs dans la table recette qui stocke la liste des ingrédients de la recette.
Et quand tu envoies le comis faire les courses, comment fais-tu ?