Je suis en train de coder un CRM pour ma boîte, dont un module de gestion des stocks.
J'ai réussi à le faire fonctionner, mais je bataille beaucoup pour la gestion des tailles. A vrai dire, certains items comme "téléphone portable" sont de tailles uniques, mais j'ai surtout besoin de pouvoir lister les chaussures de sécurité par pointure (de 36 à 47).
Et ça coince au niveau de ma logique; je n'arrive pas à faire une structure propre et pratique.Voici l'existant :
Table 'epi_list'
Elle liste les noms des items, "téléphone portable", "gilet", "chaussures" et le type de taille. 1 = taille haut, 2 = taille bas, 3 = pointure, 4 = par défaut, taille unique.
Ensuite, la table 'epi_list', qui répertorie les stocks effectifs sur chaque site (car oui, nous envoyons nos équipements de sécurité sur des sites situés partout en France). Par exemple, 2 téléphones peuvent se trouver à Paris, 2 gilets à Toulouse.
Cette table est dégueulasse, je m'en excuse d'avance.
Le code est le suivant d/i = disponible indisponible, th tb p = taille haut, taille bas, pointure, s 38 = taille /pointure.
(on ne voit pas tout sur le screen)
Enfin, "epi_employee", sur laquelle je définit l'appartenance du matériel de sécu à chaque employé. Pour reprendre l'exemple précédent, le téléphone à Paris peut être à MR. X et le gilet de toulouse à Mme. Y.
Enfin, je propose la possibilité à l'admin du CRM d'ajouter et supprimer des équipements et des objets, donc il faut qqchose de neutre. Si demain je déploie des gants avec des tailles, il faut que ce soit flexible.
Voilà, j'ai du mal à mieux formuler ma demande mais je galère à faire un PHP propre car la base de mes tables sont un peu foireuses, si vous avez un modèle plus propre et simple à proposer, je prend :)
Oui pas bête, mais par exemple dans un formulaire j'aimerai afficher une liste des items (dans un select), par taille.
Donc en gros que la liste déroulante affiche :
Gilet taille S
Gilet taille M
etc...
Sauf que si je fais une boucle de la table epi_items, j'aurai seulement une occurence de "Gilet".
Le pb de mon exemple c'est que les select proviennent d'une boucle et que leur valeur ne renvoient à rien. Et que si je définit ça manuellement, je perd le côté flexible d'ajouter et supprimer des objets
Ok merci, mais je ne vois pas en quoi ça répond à mes attentes. Enfin, vous avez un exemple de jointure qui pourrait débloquer une partie de ma situation ? Car je fais les jointures anciennes génération (avec le where)
La différence entre une jointure "ancienne génération" et une jointure "nouvelle génération" se trouve dans la syntaxe, mais c'est surtout une question d'ordre et de nouveaux mots-clés.
-- Là où tu avais
SELECT
*
FROM
table1,
table2
WHERE
table1.champ = table2.champ
-- Tu aurais maintenant
SELECT
*
FROM
table1
INNER JOIN
table2
ON
table1.champ = table2.champ
-- Et en cas de plusieurs tables
SELECT
*
FROM
table1
INNER JOIN
table2
ON
table1.champ = table2.champ
INNER JOIN
table3
ON
table2.champ = table3.champ
-- Un seul nom de table avant INNER JOIN
-- Un seul nom de table entre INNER JOIN et ON
-- Note que la partie ON fait partie de la jointure, on ne peut pas faire ce qui suit
SELECT
*
FROM
table1
INNER JOIN
table2
INNER JOIN
table3
ON
table1.champ = table2.champ
AND
table2.champ = table3.champ
Ce qui revient plus ou moins à :
séparer les noms de tables avec INNER JOIN
après un INNER JOIN et le nom d'une autre table, mettre ce que tu avais dans le WHERE et qui concernait les deux tables après ON.
Attention, tu ne pourras plus lister les tables en les séparant avec des virgules dès que tu utiliseras les jointures "nouvelle génération", cela résultera en des erreurs de syntaxe peu claires et qui ne font pas nécessairement penser à ce genre de souci.
Tu es plus que un problème base de données que Php là.
Au minimum, il te faudrait une table pour les personnels, une pour les sites, une pour les articles (et même une pour les tailles dé préférence), puis les tables qui vont lier tout ça : une table stock avec les objets "réels" donc un article, sa taille éventuelle, son nombre, puis également une table de lien entre sites et personnels.
Après on peut affiner, mais ça te permettrait déjà de débuter.
pour compléter ce que disait Ymox, tu ne peux justement pas te contenter de jointures "avec WHERE" puisque ça ne fait que des jointures internes. Tu auras besoin de jointures externes également, par exemple pour lister tous les personnels avec leurs articles dans le cas où des personnes n'auraient aucun article.
Philodick, en réalité, ces tables existent, je suis parti du principe que c'était clair, j'ai juste partagé mes tables autour de la gestion des stocks. Mais evidemment j'ai des tables pour les sites (clients), les employés (employees), etc.
Je ne débute pas en PHP, disons que je ne suis pas un professionnel et code le plus clairement possible sans pour autant être dans les normes des dev.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.
Keep It Simple Stupid - SF4 conf Swift - Cours 1/4 SF4 - Exceptions PDO - Formes Normales
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.