Discussion :

[Alexdezark]

Bonjour à tous,

Je cherche le meilleur moyen de stocker une liste dans un champ.

Explication :

prenons par exemple de la vente en ligne, un client commande 6 articles, comment stocker ces 6 articles dans un champ, quel doit être le type de ce champ ?

Pour le moment j'en suis à un champ de type TEXT dans lequel je stocke les identifiants uniques de chaque article en les séparant par des "/", pour récuperer ma liste d'objets je suis obligé de faire un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

explode("/", $resultat_requete)

ce qui exclut donc toute possibilité de jointure pour récupérer le nom du produit dans la même requête par exemple.

Si je stocke les quantités d'articles commandés de la même manière dans un autre champ je suis obligé de faire une manip supplémentaire pour créer un tableau de correspondances.

A ma connaissance il n'y a pas de TYPE ARRAY qui permettrait de stocker un tableau de données.

Avez-vous quelques conseils à me donner pour stocker des listes de la manière la plus exploitable possible ?

Merci d'avance pour vos réponses

[CinePhil]

Tu parles de 'champ' :
- du formulaire de ton appli ?
- de la table qui stocke les données ?

S'il s'agit du champ de la table, il s'agit en fait d'une colonne de la table et pas d'un champ, appelletion qui devrait justement être réservée aux champs des formulaires.

Passons au problème :

un client commande 6 articles

MCD :
client -0,n----commander----0,n- article

Tables :
client (cl_id, cl_nom...)
article (art_id, art_nom...)
commander (cmd_id_client, cmd_id_article, cmd_quantite...)

Problème avec ce modèle, un client ne peut commander qu'une seule fois un article.
2 solutions :
1) ajouter la date de commande dans la clé primaire de la table commander
(cmd_id_client, cmd_id_article, cmd_date, cmd_quantite...)

2) traiter d'une part la commande et en dessous les lignes de commande
MCD :
client -0,n----passer----1,1- commande -1,n----concerner----0,n- article

Tables :
client (cl_id, cl_nom...)
article (art_id, art_nom...)
commande (cmd_id, cmd_id_client...)
ligne_commande (lc_id_cmd, lc_id_article, lc_quantite...)

[Alexdezark]

Bonjour CinePhil et merci de ta réponses,

Alors effectivement par champ j'entendais colonne.

J'ai différentes colonnes

ID => INT auto_increment
date => DATE (date de la commande)
Client => INT (l'identifiant unique du client dans ma table clients)
articles => TEXT (les identifiants uniques des articles séparés par des / )
quantite => TEXT (la quantité pour chaque article séparé par des /)

à chaque commande se réfère donc un client, une date et des articles ainsi que la quantité commandée pour chaque article.

Ce qui ne me plait pas c'est la façon dont je stocke articles et quantités dans la base de donnée car cela ne permet pas de manipulations faciles (ou directes) du contenu de cette colonne.

Je suis obligé de récupérer puis de traiter ces données avant de pouvoir les rattacher à ce à quoi elles correspondent dans ma table "articles" qui va contenir le nom de l'article, son prix, sa quantité disponible...

Ce que je cherche à savoir c'est si il existe un moyen plus "propre" pour stocker une liste d'articles que mon système de chaine de texte avec / comme délimiteur.

[CinePhil]

Ce que je cherche à savoir c'est si il existe un moyen plus "propre" pour stocker une liste d'articles que mon système de chaine de texte avec / comme délimiteur.

La bonne solution est dans mon message précédent.

[Alexdezark]

Effectivement je n'avais pas tout compris.

Admettons maintenant que je veuille proposer des lots d'articles.

je crée une table "lots" ou je vais chercher à définir de quoi est constitué chaque lot.
Le lot ID=1 serait par exemple constitué des articles 1 et 5 et 12 et 52. etc.

Le type ENUM permettrait-il par exemple de stocker ces valeurs, en disant que les valeur autorisées sont celles contenues par la colonne ID ( auto_increment) de la table articles ?

[RunCodePhp]

La bonne solution est dans mon message précédent

+1

Si c'est du e-commerce, alors ce dont tu tente de mettre en place c'est une gestion du "panier" (ou du caddie).

Il faut une table "panier", avec les relations sur tes autres tables existantes comme te l'a démontré CinePhil.

Cependant, la gestion d'un panier un un peu plus compliqué que ça, car une personne peut naviguer sous 2 formes différentes :
- Soit non identifier : Ce qui empêchera totalement l'enregistrement du panier dans la table "panier". Pas d'ID du client.
L'enregistrement du panier devra alors se faire dans les sessions.

- Soit la personne est identifiée, donc a un compte client et donc un ID de client. Ici, il sera possible d'enregistrer son panier dans la Bdd.
S'il revient un autre jours (même 1 mois plus tard), il récupérera son panier s'il n'avait pas commander.


ID => INT auto_increment
date => DATE
Client => INT
articles => TEXT -> Plutôt un INT UNSIGNED (l'ID du produit de la table "produits"
quantite => TEXT -> Plutôt un INT UNSIGNED (un entier non négatif)

[Alexdezark]

Bon mon exemple de vente en ligne c'était juste un exemple.

en quoi la réponse de CinePhil est la bonne solution pour stocker les articles d'une commande

J'ai déjà mon système de panier, de client connu ou pas connu de stockage dans une table provisoire supprimée au bout de X jours si le client n'est pas revenu etc..

Ce que je cherche est beaucoup plus général :

Comment doit être stockée une liste d'éléments dans une BDD.

Par exemple mon histoire de lots constitués de plusieurs articles comment stocker la liste des articles qui constituent un lot ?

Ou mise en place de cartes d'abonnement donnant droit à des activités, comment stocker la liste des activités qui correspondent à telle ou telle carte ?

Le seul moyen que j'ai trouvé pour le moment de stocker cette énumération c'est ma chaine de caractères.

En gros : est-ce qu'il n'existe pas un type de colonne permettant de stocker un Array ?

[CinePhil]

Admettons maintenant que je veuille proposer des lots d'articles.

je crée une table "lots" ou je vais chercher à définir de quoi est constitué chaque lot.

Un lot est une entité en soi. On peut établir le MCD suivant :
lot -1,n----Contenir----0,n- article

Et les tables qui en découlent :
lot (l_id, l_nom, l_prix...)
article (art_id, art_nom...)
contenu_lot (cl_id_article, cl_id_lot, cl_quantite...)

ENUM sert à définir les seules valeurs possibles pour une colonne. Par exemple, pour une table de personnes, si on veut stocker le sexe de la personne on peut définir une colonne de type ENUM :
sexe ENUM('M', 'F') DEFAULT NULL

EDIT

Par exemple mon histoire de lots constitués de plusieurs articles comment stocker la liste des articles qui constituent un lot ?

Voir ci-dessus.

Ou mise en place de cartes d'abonnement donnant droit à des activités, comment stocker la liste des activités qui correspondent à telle ou telle carte ?

Même principe !
MCD :
carte_abonnement -0,n----proposer----0,n- activite

Tables :
carte_abonnement (ca_id, ca_numero, ...)
activite (act_id, act_nom...)
carte_activite (cac_id_activite, cac_id_carte...)

Le seul moyen que j'ai trouvé pour le moment de stocker cette énumération c'est ma chaine de caractères.

Très mauvais !

En gros : est-ce qu'il n'existe pas un type de colonne permettant de stocker un Array ?

Ca existe dans certains SGBD mais c'est fortement déconseillé car cela dénormalise la BDD et ça pose plein de problèmes pour ensuite chercher les données dans le tableau de données, même s'il existe probablement des fonctions propre au SGBD pour naviguer dans ce foutoir que je ne souhaite même pas connaître !

Principe général : Dans une base de données relationnelle, une ligne de table = une information unique.

Je crois que tu devrais passer par un tuto de modélisation des données.

[Alexdezark]

Merci pour le lien

Je vais étudier ça sérieusement !

Principe général : Dans une base de données relationnelle, une ligne de table = une information unique.

Dans ma table "clients" je veux savoir toutes les commandes que m'a passé mon client : "ID=15"=>"DUPOND" => "MARCEL"

Si je ne stocke pas la liste de ses commandes je dois passer en revue toute ma table "commandes" pour trouver celle ou l'ID client est 15 ?

[CinePhil]

Dans ma table "clients" je veux savoir toutes les commandes que m'a passé mon client : "ID=15"=>"DUPOND" => "MARCEL"

Si je ne stocke pas la liste de ses commandes je dois passer en revue toute ma table "commandes" pour trouver celle ou l'ID client est 15 ?

Dans la table "clients", tu ne stockes que les infos sur les clients !
Par exemple, ta table "clients" (sans 's' ce serait mieux) peut avoir la structure suivante :
client(cl_id, cl_nom, cl_prenom, cl_adresse, cl_id_ville, cl_telephone, cl_adrel)

Dans la table des commandes, tu ne stockes que les infos sur les commandes, dont l'identifiant du client qui a passé commande :
commande (cmd_id, cmd_id_client, cmd_date, cmd_total_ht)

Si tu veux savoir quelles commandes a passé le client d'identifiant 15, tu fais simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT cmd_id, cmd_date, cmd_total_ht
FROM commande
WHERE cmd_id_client = 15

Si tu ne connais que l'adrel du client, tu fais une jointure entre les deux tables pour obtenir le même résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT c.cmd_id, c.cmd_date, c.cmd_total_ht
FROM commande AS c
INNER JOIN client AS cl ON cl.cl_id = c.cmd_id_client
WHERE cl.cl_adrel = 'toto@free.fr'

[Alexdezark]

Merci de ta réponse.

Mes questions sont simplistes mais je pense ne pas être le seul à me les poser.

C'est à dire que pour le fonctionnement d'une BDD c'est mieux de chercher le contenu de ma colonne id_client parmis 250 000 lignes que de stocker dans mon client cl_cmd="212/318"

il vaut mieux :
Chercher dans toute la table commande où id_client=15
pour chaque identifiant unique récupéré parcourir la table "article_commande" pour voir quels sont les articles dont la colonne "commande" correspondra à ces identifiants.

Plutot que de recuperer mes 2 numéros de commande dans une colonne prévue pour ça ( "212/318")
recuperer dans les 2 commandes 212 et 318 des listes d'articles sous une forme : "547/878/121"

c'est bien ça ?

[CinePhil]

C'est à dire que pour le fonctionnement d'une BDD c'est mieux de chercher le contenu de ma colonne id_client parmis 250 000 lignes que de stocker dans mon client cl_cmd="212/318"

il vaut mieux :
Chercher dans toute la table commande où id_client=15
pour chaque identifiant unique récupéré parcourir la table "article_commande" pour voir quels sont les articles dont la colonne "commande" correspondra à ces identifiants.

Plutot que de recuperer mes 2 numéros de commande dans une colonne prévue pour ça ( "212/318")
recuperer dans les 2 commandes 212 et 318 des listes d'articles sous une forme : "547/878/121"

Si tu veux savoir quels articles ont été achetés par le client d'adrel 'toto@free.fr', tu fais des jointures en plus.

Reprenons la structure que j'ai proposée :
client (cl_id, cl_nom, cl_adrel...)
article (art_id, art_nom...)
commande (cmd_id, cmd_id_client, cmd_date...)
ligne_commande (lc_id_cmd, lc_id_article, lc_quantite...)

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT cd.cmd_id, cd.cmd_date, a.art_nom, lc.lc_quantite
FROM article AS a
INNER JOIN ligne_commande AS lc ON lc.lc_id_article = a.art_id
  INNER JOIN commande AS cd ON cd.cmd_id = lc.lc_id_cmd
    INNER JOIN client AS cl ON cl.cl_id = cd.cmd_id_client
WHERE cl.cl_adrel = 'toto@free.fr'

Il ne faut pas avoir peur des jointures, les SGBD sont particulièrement optimisés pour ça.
Il faut bien entendu que les tables soient correctement indexées pour que ça fonctionne rapidement :
- index sur toutes les clés étrangères ;
- index sur les colonnes les plus recherchées.

[Alexdezark]

J'avoue qu'une bonne indexation ça reste un peu un mystère pour moi

J'ai lu ceci qui ne m'a pas vraiment éclairé :http://dev.mysql.com/doc/refman/5.0/...l-indexes.html

Comment indexerais-tu le modèle que tu me donne en exemple ?

De plus :

- index sur les colonnes les plus recherchées.

Oui mais si on veux sortir des statistiques de commandes par rapport à la date ou la région du client ou les produits les plus demandés etc..

On va interroger notre BDD dans tous les sens...

[CinePhil]

J'avoue qu'une bonne indexation ça reste un peu un mystère pour moi

Voir les articles de SQLPro à ce sujet.

Comment indexerais-tu le modèle que tu me donne en exemple ?

Je reprends le modèle :

client (cl_id, cl_nom, cl_adrel...)
article (art_id, art_nom...)
commande (cmd_id, cmd_id_client, cmd_date...)
ligne_commande (lc_id_cmd, lc_id_article, lc_quantite...)

Et ce que j'ai dit sur l'indexation :

- index sur toutes les clés étrangères ;
- index sur les colonnes les plus recherchées.

Ce qui donne :
Table client :
- art_id est la clé primaire et sera automatiquement indexée.
- Un index sur le nom du client me semble très utile.
- Si la recherche se fait sur l'adrel comme je l'ai donné en exemple, indexer aussi cette colonne.

Table article :
- Idem pour la clé primaire, c'est automatique.
- Idem sur le nom de l'article.

Table commande :
- Idem pour la clé primaire.
- La clé étrangère cmd_id_client est à indexer obligatoirement, sous peine de ne pouvoir la déclarer clé étrangère.
- Si la recherche se fait souvent sur la date, indexer cmd_date.

Table ligne_commande :
- Petite subtilité sur la clé primaire : elle sera composée de deux colonnes, l'index sera donc lui aussi sur ces deux colonnes dans l'ordre où les colonnes sont données, ce qui a son importance. Il faut mettre la colonne la plus discriminante en premier, c'est à dire celle qui aura le plus grand nombre de valeurs différentes.
- Il faut indexer séparément la deuxième colonne de la clé primaire qui est également une clé étrangère.
- La première colonne de la clé primaire est elle aussi une clé étrangère mais elle est déjà indexée par sa première position dans la clé primaire donc il est inutile de l'indexer séparément.
- Il est peu probable qu'on fasse des recherches sur les quantités. Il n'est pas utile d'indexer cette colonne.

Oui mais si on veux sortir des statistiques de commandes par rapport à la date ou la région du client ou les produits les plus demandés etc..

On va interroger notre BDD dans tous les sens...

La région du client sera une clé étrangère => à indexer.
Les produits les plus demandés seront obtenus par une requête. Ce n'est pas une information enregistée physiquement en BDD, c'est une donnée calculée.

[Alexdezark]

Merci de m'avoir apporté toutes ces réponses

Je vais déjà bien faire le tour de tes réponses et des liens que tu m'as donnés.

Et je reviendrai après si j'ai d'autres questions.

Je ne mets pas le tag "résolu" tout de suite mais ce sera fait dès que je serai sûr d'avoir tout compris (houla c'est ptet un peu prétentieux ça...)

Bonne soirée à tous