Discussion :

[jeremm]

Bonjour,

J'aimerai avoir votre avis concernant la modification de ma base de données mysql, attaqué via php.

Je propose 2 types d'objets différents à mes visiteurs, appelons les objets A et B. Actuellement j'ai donc 2 tables "table_objetA" et "table_objetB" dont les colonnes en commun sont ID (clé primaire), email, et la date ; plus des caractéristiques particulières pour chacun des objets. Les colonnes pour les 2 tables sont donc différentes entres elles. Lorsqu'un visiteur achète l'un ou l'autre ou les deux objets, j'insère les informations dans les tables en question.

Mon soucis est lorsque l'utilisateur dans son 'dashboard' veut récupérer les informations de ses achats, avec un ID particulier.
Je fais beaucoup trop de requêtes, car je dois requêter une fois dans ma table "table_objetA" si l'ID existe et si oui alors j'affiche, puis idem dans "table_objetB", sans savoir s'il y a des données ou non.. Du coup tout ça, c'est lent.

A l'avenir il est fort probable qu'un 3ème type voit le jour, j'aurais donc "table_objetC"...

Ma question : comment optimiser mes tables ? Je me doute qu'il y a un moyen pour factoriser cela, mais comment ?!
Je suis prêt à repartir from scratch si besoin.

En espérant avoir été clair, Merci !

[François M.]

Bonjour

Désolé, mais c'est vraiment nébuleux.

Que contiennent les tables "objet_a" et "objet_"b ?
Pourquoi n'y a t-il pas de table "utilisateur" ?

[jeremm]

Non, il n'y a pas de table utilisateur.

Table_A :
id (incrémental, cle primaire), num_serie, email_user, date_achat, quantité, coloris, achat_confirmé (boolean)

Table_B :
id (incrémental, cle primaire), num_serie, email_user, date_achat, quantité, type_de_bois, structure (boolean), achat_confirmé (boolean)

num_serie étant un numéro unique que je génère, que l'utilisateur connait, qui permettra ensuite de rechercher tous ses achats pour affichage dans le dashboard.

Oui c'est moche..

[François M.]

C'est déjà pas très catholique de ne pas avoir de table utilisateur.

Ensuite, je ne comprends pas l’intérêt d'avoir une table par type de produit vendu, et de ne pas avoir de tables répertoriant les produits à vendre.

Bref, ça ne ressemble pas à grand chose en première approximation.

[jeremm]

Au début il n'y a avait qu'un produit donc ça fonctionnait bien maintenant l'offre grandit donc forcément ça devient usine à gaz..
C'est pour cela que je viens demande de l'aide.

Que me conseilles-tu ?

Une table "utilisateur" (id, email)
Une table "produits" (quelles colonnes ?!)
D'autres ?

[François M.]

A minima :

- une table "client"
- une table "produits"
- une table "commandes" (a minima : client, date commande, état de la commande, montant payé, etc ...)
- une table "ligne de commande" (a minima: id de commande, id de produit, quantité)


Il s'agit bien sur d'un strict minimum, bien insuffisant dans la pratique (et à condition de ne pas gérer encaissement, avoirs, remises, stocks, historique de prix, etc ...)

Pour le détail ne connaissant pas ton métier, je ne peux pas du tout répondre à ta place.