Script PHP et SQL : Catalogue de produit

Bonjour à tous les développeurs,
Je viens aujourd'hui vers vous afin de quémander de l'aide.

---------------------------------------------------------

Je vous explique en quelques étapes ce que je souhaites réaliser :
Je souhaite en fin de compte réaliser un "catalogue" présentant mes produits de ma boulangerie, selon des catégorie définies.

J'ai pour le moment créé une table SQL, néanmoins je ne sais pas si elle est bien faire en fin de compte :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

-- -- Structure de la table `CATALOGUE_Produits` --   CREATE TABLE `CATALOGUE_Produits` ( `ID` int(10) unsigned NOT NULL auto_increment, `CATEGORIE` text collate latin1_german2_ci NOT NULL, `TITRE` text collate latin1_german2_ci NOT NULL, `IMAGE` text collate latin1_german2_ci NOT NULL, `DESCRIPTION` text collate latin1_german2_ci NOT NULL, `PRIX` decimal(10,2) NOT NULL, `PIECE` int(2) NOT NULL, `POIDS` int(2) NOT NULL, `BOITE` int(2) NOT NULL, `PERS` int(2) NOT NULL, `CMD` int(2) NOT NULL, `SAISON` int(2) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=6 ;

---

En quelques lignes, j'arrive alimenter la BDD sans soucis:

Code:

---

1 2 3 4

$db = @mysql_pconnect($Serveur_db, $User_db, $Passe_db); @mysql_select_db($Base_name, $db);   @mysql_query("INSERT INTO CATALOGUE_Produits(CATEGORIE, TITRE, IMAGE, DESCRIPTION, PRIX, PIECE, POIDS, BOITE, PERS, CMD, SAISON) VALUES('$Categorie','$Titre','$File_name','$Description','$Prix_OK','$Piece','$Poids','$Boite','$Pers','$CMD','$Saison')",$db) ;

---

Je renseigne dans la colonne "CATEGORIE" le nom de ma catégorie qui me servira par la suite a afficher les résultats selon les catégories choisies. Chaque catégorie sera affiché sur une page différente, donc je réaliserai des requêtes type "Afficher ... Where CATEGORIE == ....".

---------------------------------------------------------

Mes questions sont donc multiples :
1. Est-ce que je commence bien selon ce que je veux faire? Ou alors je vais droit dans le mur, et il y a une meilleure solution ?
2. Est-ce possible d'avoir une aide pas a pas, ou je code, et on me dit si ainsi ca va, ou alors si il n'y a pas meilleure solution?

Je suis prêt a remercier la personne qui m'aidera par mes conaissances ou mon aide en retour (graphisme, flash, ...).

Merci d'avance,
Fab.

Sur la table j'ai deux remarques :
1 : éventuellement créer une table des catégories (avec juste 2 champs un ID et un libelle) et ne mettre dans la table principale que l'ID. Cela permet de changer le nom des catégories sans tout casser et cela évite les erreurs de frappe.

2 : le champ Description devrait être assez long : vous avez des Longtext qui permettent de saisir un descriptif déaillé.

Pour les photos je vous conseille de ne mettre dans la base que le nom exact du fichier image et de ranger vos images dans un répertoire à part
Par contre à réaliser cela en PHP et surtout faire ensuite quelque chose d'attrayant risque de ne pas être facile.

Citation:

---

Envoyé par Delphi-ne

Sur la table j'ai deux remarques :
1 : éventuellement créer une table des catégories (avec juste 2 champs un ID et un libelle) et ne mettre dans la table principale que l'ID. Cela permet de changer le nom des catégories sans tout casser et cela évite les erreurs de frappe.

2 : le champ Description devrait être assez long : vous avez des Longtext qui permettent de saisir un descriptif déaillé.

Pour les photos je vous conseille de ne mettre dans la base que le nom exact du fichier image et de ranger vos images dans un répertoire à part
Par contre à réaliser cela en PHP et surtout faire ensuite quelque chose d'attrayant risque de ne pas être facile.

---

Mais aprés comment lier les deux tables en fin de compte ? Sachant que en théorie les catégories ne changeront pas ensuite.

Concernant les images, en effet je ne stock que le nom de l'image, qui est dans un répertoire sur le FTP.

C'est sur que je sais que ca ne sera pas facile lol, mais je voudrais quand même essayer car je ne trouves aucun script tout fait.

Merci d'avance,
Fab.

Voilà une requete sur 2 tables

Code:

---

1 2 3 4

Select * From CATALOGUE_Produits Join CATALOGUE_Categories On CATALOGUE_Produits.CATEGORIE = CATALOGUE_Categories.id

---

L'idée est de mettre dans la clause le champ de la première table ) au champ de la seconde

Bonjour,

Comme le souligne Delphi-ne, il serait judicieux de gérer les catégories dans une table indépendante.

Plusieurs remarques supplémentaires :
- essayer si possible d'encoder tout en UTF-8 (base de données, fichiers php js css...),
- comme c'est parti, tu vas créer une base de données relationnelle, je te conseille très fortement de remplacer le moteur MyISAM par InnoDB qui est plus spécifique aux bases relationnelles,
- et fais attention au données temporisées : le prix va certainement augmenter, il serait dommage d'avoir à créer une nouvelle référence juste pour cette raison. De même, pour le poids... (pas sûr, à voir)

Bon courage :ccool:

Citation:

---

fais attention au données temporisées

---

Concrêtement si j'ai bien compris cela reviendrait à créer une table juste pour les prix avec comme structure :

Code:

---

1 2 3 4

Date de prise d'effet du prix DateTime Date de fin d'effet : DateTime ID Produit : BigInt Prix Decimal

---

et pour les requetes :

Code:

---

1 2 3 4 5 6 7

Select * From CATALOGUE_Produits Join CATALOGUE_Categories On CATALOGUE_Produits.CATEGORIE = CATALOGUE_Categories.id Join CATALOGUE_Prix On CATALOGUE_Produits.ID = CATALOGUE_Prix.ID Produit And Now Between Date de prise d'effet And Date de fin d'effet

---

Il va s'amuser. C'est effectivement très clean mais cela complexifie pas mal les choses. Il faut vraiment voir si fonctionnellement le jeu en vaut la peine.
Ce qu'il faut donc c'est se définir une règle pour le nommage des champs dans chaque table.
Au moins si le nombre de tables augmente cela restera clair

salut,

y a de l'idée dans ce que vous lui conseillez mais un peu de précisions s'impose...:zoubi:

d'abord tout partout UTF-8... 10000 fois oui latin et autres encodages (iso-8859-?) sont en perte de vitesse car ils sont super contraignants pour au final un gain de place pas plus important que l'utf-8 permet... à noter, pour ta culture, que tous sont un encodage spécifique de l'unicode:

• unicode: 4 octets
• iso...: 1 ou 2
• utf-8: 1 à 6

la valeur entre parenthèse pour les entier c'est la précision (nombre de chiffres significatifs) pas la taille de la colonne. elle est déterminé par le type d'entier:

• tinyint, 1 octet
• smallint, 2
• mediumint, 3
• int, 4
• bigint, 8

pour un identifiant on utilise le qualificateur unsigned qui permet de ne pas perdre les valeurs négatives et doubler le potentiel de valeurs possibles. c'est bien fab tu le fais...
:ccool:

varchar (0 à 256 caractères ou 0 à 1024 selon la version de mysql) est plus adapté que text (0 à 65536 cractères) pour les descriptifs courts, titres, etc...

text est adapté aux descriptif long.
longtext si tu ponds un roman...

je vais pas te bourrer le mou avec toute la théorie des différentes formes normales des tables (en gros l'art et la manière d'obtenir un ensemble de tables les plus efficace possible) mais résumons les choses:

Citation:

---

si une colonne contient des données (texte, c'est surtout là que ça vaudra le cout) répétitives alors il est rentable de créer un nouvelle table qui liste ces données de manière unique et d'y faire référence dans la table d'origine par une valeur numérique identifiant chacune de ces valeurs (texte ou autre) de manière unique
on utilisera alors un jointure pour récupérer la valeur.
on a ainsi mâché aussi le boulot pour la mise en place d'une éventuelle recherche sur cette colonne

---

ici ça s'applique à catégories... la plupart de tes catégories vont apparaitre sur plusieurs produits donc tu vas drastiquement compacter ta table produits en virant une colonne texte de ta tables produits et en la remplaçant par une colonne tinyint (si tu me dis que tu ponds plus de 256 catégories de produits, j'aurais du mal à te croire), c'est ce qu'on appelle alors une clé étrangère (car elle référence la clé primaire d'une autre table, elle a les même caractéristiques qu'elle, elle est auto indexé en innodb mais pas en myisam)

on dimensionne toujours les index au mieux en fonction du nombre de valeur possible car sinon tu bourres le buffer d'index qui accélère les recherche de valeur pour les recherches, jointures, classements, etc...

c'est aussi pour ça qu'on veut avoir des tables en forme normales car sinon tu bourres le buffer de lignes qui sert autrement et évite d'aller relire les tables...

les jointures:

• toujours utiliser le mot clé JOIN, la table juste à sa droite est la table de droite dans la relation. tu as:
• cross join... le produit de table (on distribue chaque ligne de la table à droite pour compléter chacune de celle de la table de gauche)... rarement utilisé de nos jours
• natural join, jointure naturelle (on ramène les lignes correspondant aux les colonnes du même nom dans les 2 tables)... très dangereux si tu es amené à faire évoluer la structure de tes tables
• (left) join... jointure à gauche (on ramène toujours les données de chaque ligne de la table de gauche et éventuellement complétées par celle correspondant aux conditions de jointure dans la table de droites, on répète celle de la table de gauche pour chaque correspondance à droite)
• inner join... comme la jointure naturelle mais tu précises explicitement les conditions de jointure (ne portant alors pas forcément que sur une égalité de valeur entre colonnes dans les 2 tables)

on précise les conditions de jointure avec le mot clé on ou using dans des cas limités...
on n'utilise JAMAIS * surtout avec une jointure, sous peine d'avoir des performance amoindrie (tu rapatries toutes les données au lieu de juste ce dont tu as besoin) et d'une relecture pour la maintenance pitoyable...
on utilise des alias de table pour toujours explicitement dire d'où viennent les colonne mais de manière compacte:

Code:

---

1 2 3

select t.a, t.b, m.d from truc t inner join machin m on m.id=t.c

---

pour la gestion des prix, y a plus simple delphine:
ce qui évite d'avoir à chercher et mettre à jour une éventuelle date de fin de période précédente... et de devoir mettre une fin de période avec une date lointaine bidon pour la fin de période (sous peine de ne plus avoir de prix ou des incohérences si on oublie de faire toute ces actions)...

Code:

---

1 2 3 4 5 6 7 8

create table prix( id mediumint unsigned not nul auto_increment, #24 millions de possibilités est suffisant idproduit smallint unsigned not null,#65536 produits possibles, ce type doit être le même que dans la table référencée valeur decimal(10,2) not null, debut date not null, constraint pk_prix primary key (id), constraint fk_prix_produit foreign key(idproduit) references produits(id) )engine=innodb auto_increment=1

---

le prix actuel des produits:

Code:

---

1 2 3

select idproduit,max(debut),valeur from prix group by idproduit

---

la table produits pourrait ressembler à ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

CREATE TABLE `Produits` ( `ID` smallint unsigned NOT NULL auto_increment, `IDCATEGORIE` tinyint unsigned NOT NULL, `IDBOITE` tinyint unsigned NOT NULL,#à expliciter plus pour voir le bon typage... `IDSAISON` tinyint unsigned NOT NULL,#à expliciter plus pour voir le bon typage... `PIECE` tinyint unsigned NOT NULL, `POIDS` smallint unsigned NOT NULL default 0,#le poids est positif ou 0 `PERS` int NOT NULL,#à expliciter plus pour voir le bon typage... `CMD` int NOT NULL,#à expliciter plus pour voir le bon typage... `TITRE` varchar(255) NOT NULL, `IMAGE` varchar(255) NOT NULL, `DESCRIPTION` text NOT NULL, constraint pk_produit PRIMARY KEY (`ID`), constraint fk_produits_categorie foreign key(`IDCATEGORIE`) references categeories(id), constraint fk_produits_boite foreign key(`IDBOITE`) references boites(id), constraint fk_produits_saison foreign key(`IDSAISON`) references boites(id) ) ENGINE=innodb AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci ;

---

le prix d'un article en particulier:

Code:

---

1 2 3 4 5 6 7 8

select p.titre, px.valeur from produits p left join ( select idproduit,max(debut),valeur from prix group by idproduit ) px on px.idproduit=p.id where p.id=2

---

J'ai quand même mis un :plusser: pour l'ensemble du message mais ceci est beurk !

Citation:

---

le prix actuel des produits:

Code:

---

1 2 3

SELECT idproduit,max(debut),valeur FROM prix GROUP BY idproduit

---

---

Cette requête ne fonctionne que chez MySQL qui est le plus mauvais des grands SGBD.
Elle peut induire des erreurs car la colonne valeur devrait faire partie du GROUP BY sous peine de se voir affecter la première valeur trouvée par le SGBD.

La bonne requête serait plutôt celle-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT p.idproduit, p.valeur FROM prix INNER JOIN ( SELECT idproduit, max(debut) AS dernier_debut FROM prix GROUP BY idproduit ) tmp ON tmp.idproduit = p.idproduit AND tmp.dernier_debut = p.debut

---

oui je sais phil, mais pour cette requête ça passe allégrement :mouarf:

sinon ta requête ou la mienne en rajoutant valeur dans le group by et hop le tour est joué pour être exhaustif et béton... tu as raison :ccool:

Citation:

---

sinon ta requête ou la mienne en rajoutant valeur dans le group by et hop le tour est joué

---

Si tu te contentes d'ajouter valeur au GROUP BY dans ta requête, tu auras autant de lignes qu'il y a de couples {idproduit, valeur} donc potentiellement plusieurs valeurs pour un produit alors que tu cherches la valeur la plus récente pour chaque produit.

oui il faut rajouter un order by puis un limit 1 par exemple ce qui la rend moins efficace que la tienne du coup :ccool:

Bonsoir.
Je me penche actuellement sur un autre soucis, plus facile a régler je penses, et me remettrai ensuite sur le code. Je pense d'ici mi octobre.

Merci de l'aide encore,
Fabrice.

J'ai réfléchi à cet échange d'idées.
Je pense que la date de fin peut quand même être intéressante par exemple pour une promotion.

On a un article vendu habituellement 50 euros. On peut aussi définir une période d'une semaine (donc date de début, date de fin) avec un prix plus attractif.

Cela étant c'est vrai que l'exemple de ericd69 permet de rendre la date de fin facultative pour le prix en cours.

après tout dépend de la complexité applicative de la mise à jour que tu tiens à avoir...

les 2 sont aussi viables potentiellement mais la tienne nécessite de TOUJOURS mettre à jours la date de fin pour être viable...
donc quand tu insères une période faut toujours chercher la période en cours ouverte et la fermer et ça pose la complication d'utiliser une date future bidon que tu définis comme date limite future servant de borne extrême en cas de non limite de fin de période... tu ne peux utiliser null dans between pour la date de fin...

c'est pour ça que simplifier la définition d'un événement à son début et à l'existence d'un autre après pour définir son éventuelle fin... tu simplifies aussi tout la maintenance liée...

plus simple... moins de risque de loupé...:ccool:

dans ton exemple... comment avoir une période ouverte coupée par une période fermée et la différencier d'une période ouverte clôturée par une autre... c'est là que la complexité de la mise à jour arrive...

avec mon approche si tu définis une période elle est toujours ouverte et clôture la précédente... la logique est donc très simple pas de risque de loupé

pour reprendre ton exemple:

• tu définis un début de période avec 75€
• tu en crée un début pour une postérieure avec 50€
• tu définis enfin une dernière période avec 75€ pour rétablir l'ancien tarif...

ça rend le suivit plus simple...
dans ton cas faut être sur qu'aucune période ne se chevauche en faisant des fermetures automatiques ce qui est un peut plus lourd...