Question subsidiaire :
Comment je peux savoir, sans créer de fonction, ni de procédure, ni faire de "tests" (un SELECT avant) si la création d'un produit, d'une ligne de commande est valide, c'est-à-dire, que je n'ajoute pas un produit à une catégorie supprimée ou à une commande validé, ou une ligne de commande d'un produit supprimé.

Par avance merci de votre aide

PS : J'ai trouvé : les trigger, merci à tous

Merci [b]pascaltje[/b], j'y avais songé

[quote="mojorisin"]Je relève un autre problème dans la modèlisation ou alors certains champs ne sont pas spécifiés dans ton problème :
le prix de l'article ne doit pas être calculé a travers une relations, le changement d'un prix à un moment T entrainera alors une corruption des commandes antérieures.

Personnelement, je partirais sur une duplication des données d'article nécessaire à l'affichage des commandes (libellé, prix, reference,..) pour les même raison que que la problématique ci-dessus, les données d'une commande doivent être totalement indépendantes des données des produits car ces données doivent toujours refleter ce que l'internaute à acheté au moment de son achat.[/quote]

Je n'ai pas mit produits.prix et paniers.prix, entre autre, oui.
La duplication, je sais, mais bon, j'aimerais éviter, du moins, si possible, aucune idées, je sèche, je sais, je suis exigent.
Le gérant du site ne veut voire que le prix totale dans les commandes antérieures.
Donc, si personne n'a dit, je n'ai que la duplication :(

Par avance merci de votre aide

Je relève un autre problème dans la modèlisation ou alors certains champs ne sont pas spécifiés dans ton problème :
le prix de l'article ne doit pas être calculé a travers une relations, le changement d'un prix à un moment T entrainera alors une corruption des commandes antérieures.

Personnelement, je partirais sur une duplication des données d'article nécessaire à l'affichage des commandes (libellé, prix, reference,..) pour les même raison que que la problématique ci-dessus, les données d'une commande doivent être totalement indépendantes des données des produits car ces données doivent toujours refleter ce que l'internaute à acheté au moment de son achat.

hello,

Quelques pistes :
- pour les produits : un état actif / supprimé (archivé)
- panier vs commande : une commande (un panier) est composée de lignes de commande

A+

Pascal

Je sais, il semble y avoir une ambiguïté, mais j'ai pas trouvé de meilleur nom pour désigner les produits et leur quantité inclus dans le panier, c'est une contrainte d'intégrité multiple (et qui c'est qui a bien écouté en cours d'analyse :lol:) pour obtenir la quantité à partir du produit et de la commande. Voilà en gros.

Par avance merci

Ben pour moi un panier acheté est une commande et je ne vois pas pourquoi celle-ci serait dépendante des paniers en cours (non commandés).
D'ailleurs elle pourrait contenir des produits qui ne sont plus proposés sur le site.
(si j'ai bien compris le pb)

Bonsoir à toutes et à tous,

Depuis une semaine je me triture les méninges pour résoudre le problème suivant :
Je dispose des tables suivantes :
Produits([u]pk_produit[/u], nom, ..., fk_categorie#)
Categories([u]pk_categorie[/u], nom)
Commandes([u]fk_produit#, fk_panier#[/u], nombre)
Paniers([u]pk_panier[/u], etat, ..., fk_membre#)
Membres([u]pk_membre[/u], ...)
Voilà le souci (chaque FK pointe sur un PK, dépendance via une clef externe via PostGreSQL)
Lorsque l'on souhaite supprimer un produit, celui-ci doit rester visible dans les paniers achetés mais disparaitre des paniers en cours et des produits disponibles. Idem pour les catégories vis-à-vis des produits.
Après avoir cherché, j'ai réduit le champs des possibilités à deux options :
* Je rajoute un champs de type booléen "supprimé" et je mets des WHERE de partout
* Je me sers des différents moyens que m'offre PostGreSQL pour "casser" ses contraintes

Voilà, sachant que je ne saurais quel moyen utiliser parmi les options disponibles.
Si vous avez des éléments qui me permettent de choisir, ou une autre possibilité, je suis preneur, bref, toute aide est la bienvenue.

Par avance merci