Purge partielle d’une table

Bonsoir à tous

Citation:

---

Même si, quand même, le travail est plus facile quand on parle la même langue.

---

OK, les règles données par Djockey sont mal tournées (elles ne respectent pas leur définition telle que je l'ai rappelée au post #77).

Citation:

---

J'aurais bien vu une petite introduction pour situer le contexte

---

D'accord.

Citation:

---

Alors j'insiste, quand je vois ça :
...
je tique.

---

Pour la règle 6, Ok, elle est mal exprimée. Pour la règle 9, à part une faute d'orthographe, elle me va. Et pour les fautes, Djockey n'a pas le monopole : Je tiqueraiS moins :zoubi:

Même si j'ai commencé, je ne vais pas continuer ce soir :zzz: . J'envisage de réécrire les 15 règles.

Gluups

Citation:

---

J'espère que ça ne va pas perturber que je reprenne mon pseudo normal maintenant qu'il fonctionne.

---

Ça devrais aller je pense.

Citation:

---

J'aurais bien vu une petite introduction pour situer le contexte

---

Genre ...! c'est pour l'enregistrement des cordonnées d'un client qui vient déposer des articles. Qui seront vendus ultérieurement par l'association.

Juste pour vous donnez une idée la bourse aux livres faites en octobre 2023 a représenté 8600 articles déposés et 27% d'articles vendus.

Les régles 5, 6, 7 sont modifiées.

Règles de gestion du soft, pour une bourse aux livres.
1. Les différents statuts des codes clients (on va dire comme cela) : Déposant, ou Bénévoles, et Association.
2. Le code ZZ sera seul ayant le statut Association.
3. Le jour de la vente l’organisateur de la vente donc l’Association retiens 15% sur le prix de vente affiché sur l’article.
4. La retenue de 15% ne s’applique pas au statut bénévole et Association.
5. Un code client, de deux lettres.
un prix de vente (inscrit ultérieurement en général non enregistré dans la bdd).
6. Les articles déposés se répartissent en quatre catégories : Livres, DVD, CD, Vinyl. Nul besoin d’information supplémentaire ce n’est pas type bibliothèque.
7. Le prix de vente n’est pas enregistré c’est dû au fait que le control pour valider la qualité général, le nombre d’articles se fait quelques heure plus tard, voir jour (fastidieux pour les petites mains et du temps).
8. Les articles mis en vente peuvent avoir un état : Déposé (pour être vendus), Invendable (suite au control avant la mise en vente), et vendus.
9. Un client arrive pour déposer ces différents articles un jour XX plusieurs jour avant la vente, on Lui donne un code à deux lettres, on enregistre le Code, Nom, Prénom, Adresse, Cp, Ville, Tél, Email, nombre Livres, nombre DVD, nombre CD, nombre Vinyl.
10. Sur chaque article on appose une étiquette autocollante ou est inscrit le code à deux lettres du client et le prix de vente.
Le jour de la vente :
11. Un acheteur, passe en caisse on registre le code et le prix des articles le type d’article cela doit afficher le nombre total d’articles acheté, le nombre d’articles pour chaque catégorie avec leur prix respectif, la somme total à régler.
12. Possibilité d’annuler un article en cas d’erreur d’enregistrement a la caisse.
13. Possibilité d’avoir une facture avec la liste et prix des articles et la somme payé les coordonnées de l’association, entrer les différentes informations de l’acheteur qui sont : Nom, Prénom, Raison sociale, Rue, Cp, Ville, tel, email.
14. On enregistre la facture afin de pouvoir la retrouvée ultérieurement.
15. A la fin de la vente : On doit connaitre le nombre et type d’articles vendus, et invendus pour chaque client déposant.
16. La somme qui revient au client déposant.

Deux lettres et le prix de vente, pour le code client ?
Aïe ! J'aurais plutôt deviné qu'on enregistrait :

• un code client, de deux lettres
• un prix de vente

Comme ça, nous avons pris un peu d'avance sur la phase suivante, où nous nous occuperons des traitements. Mais ce n'est pas une mauvaise chose d'en parler, nous pouvons découvrir ainsi une propriété du prix à laquelle nous n'aurions pas pensé.

Arrive-t-il que le client formule un commentaire sur le prix ?
En arrivant, n'a-t-il pas parfois une petite idée de combien il aimerait bien tirer de ses articles, quitte à être déçu ensuite ?

Bon, reprenons.
Notre client est arrivé avec trois livres, dont un à trois euros, un à quatre euros cinquante, et un à quarante-huit euros. Mais ces prix ont été définis le lendemain du dépôt.
Il peut aussi être arrivé avec cinq CD, ayant chacun son prix.
C'est bien ça ?

Citation:

---

Envoyé par Djockey

Bonjour,
C’est pour une association, un soft réalisé par un ancien membre pour la gestion d’une bourse aux livres. Malheureusement, je n’y connais pas grand-chose.
Le but est de purger partiellement une table, afin que lors de la prochaine utilisation, on puisse en retrouver certaines lignes via un formulaire, et les afficher afin de pouvoir valider de nouveau .

Donc l’idée est de pouvoir vider les colonnes :code_deposant, Livres, DVD ,CD, date_creation, Note
Ainsi, lors de la prochaine utilisation, en remplissant le Nom ça retrouverait toutes les autres colonnes

Ci-joint : la page ajout deposant.(on peut tout faire c’est une copie pour test) https://www.cjoint.com/c/MIAaxBJyEWD

Code:

---

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

`code_deposant` int(2) NOT NULL, `nom` varchar(40) NOT NULL, `prenom` varchar(40) DEFAULT NULL, `rue` varchar(40) NOT NULL, `code_postal` varchar(5) DEFAULT NULL, `ville` varchar(40) NOT NULL, `tel` varchar(15) DEFAULT '06', `email` varchar(40) DEFAULT 'email@email.fr', `association` varchar(40) DEFAULT 'Deposant', `Livres` varchar(40) DEFAULT '0', `DVD` varchar(40) DEFAULT '0', `CD` varchar(40) DEFAULT '0', `date_creation` date NOT NULL, `Note` varchar(1001) DEFAULT '' ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='V6_08_19_01';

---

---

Bonjour, je reviens sur ton premier post, pour voir si tu peux faire évoluer ton appli selon le moins-disant, puisque c'est ton besoin.

C'est vrai que si tu veux faire une requête en écriture, sans savoir d'avance si tu as une insertion ou un update, il faut suivre ce chemin.
Fais une insertion fantaisie dans l'interface de ton phpmyadmin, pour récupérer un code SQL d'insertion propre.
Ensuite tu le copies-colles et ajoute "on duplicate key update" :
Ce qui te donnera quelque chose du genre :

Code:

---

1 2	INSERT INTO deposant VALUES(NULL, "VIARD", "Karine", "2 rue des souris", "88000", "EPINAL", NULL, NULL, NULL, NULL, NULL, NULL, NULL) ON DUPLICATE KEY UPDATE rue = "3 rue des chats", code_postal = "27000", ville = "EVREUX" /*etc...*/;

---

1) Je pose que ta première colonne est auto-increment.
2) Je pose que ta clé d'unicité (indispensable pour définir les doublons qu'on ne veut pas voir) est posée sur un couple de 2 colonnes : nom + prenom.
Entre nous, c'est très dangereux. Je travaille dans une boîte de 1000 "collaborateurs" et nous avons un doublon de ce type, du genre 2 "Nathalie LEGRAND".
Pour bien faire, si tu peux encore faire évoluer cette table, tu devrais ajouter une date de naissance. La remplir une fois avec des données fantaisie pour ton existant (du genre UPDATE deposant set date_naissance = "1900-01-01").
Puis ensuite, faire saisir la vraie date pour les nouveaux déposants.
Ta clé d'unicité devient alors posée sur 3 colonnes : nom + prenom + date_naissance.

Pourquoi Laurent et moi insistons sur cette commande SQL ? Parce qu'elle te fait faire un PHP infiniment plus simple. Tu fais une seule requête et le SQL bascule en mode insertion ou update selon les besoins.
Je te mets ici un petit topo que je faisais là-dessus sur un commentaire d'un billet de blog :

https://www.developpez.net/forums/bl.../#comment12074

Bonjour à tous,

Dendrite (Sylvie),
tes remarques portent sur les requêtes SQL, mais avant de travailler là-dessus, je pense qu'il faut revoir la modélisation (le MCD). Je ne suis pas le seul à penser cela :

Citation:

---

Envoyé par escartefigue

Cette table présente à peu près tout ce qu'il ne faut pas faire quand on modélise une base de données.

---

post #28 du 3/10...
D'ailleurs, Djockey vient de nous proposer des règles de gestion (cette nuit).


Quelques remarques ou questions sur ton post :

Citation:

---

Envoyé par Dendrite

Pourquoi Laurent et moi insistons sur cette commande SQL ?

---

Ah bon ? Ah oui, post #18, y a pile un mois !

Citation:

---

Envoyé par Dendrite

pour voir si tu peux faire évoluer ton appli selon le moins-disant, puisque c'est ton besoin.

---

Tu peux préciser, STP ?

Citation:

---

Envoyé par Dendrite

C'est vrai que si tu veux faire une requête en écriture, sans savoir d'avance si tu as une insertion ou un update, il faut suivre ce chemin.

---

Quel chemin ?

Citation:

---

Envoyé par Dendrite

Code:

---

1 2	INSERT INTO deposant VALUES(NULL, "VIARD", "Karine", "2 rue des souris", "88000", "EPINAL", NULL, NULL, NULL, NULL, NULL, NULL, NULL) ON DUPLICATE KEY UPDATE rue = "3 rue des chats", code_postal = "27000", ville = "EVREUX" /*etc...*/;

---

---

Certes, j'utilise parfois ce type de requête (et effectivement, ça simplifie grandement le code PHP), mais j'ai pour habitude de mettre les mêmes valeurs qu'on fasse un INSERT ou un UPDATE ; par exemple

Code:

---

1 2	INSERT INTO deposant VALUES(NULL, "VIARD", "Karine", "2 rue des souris", "88000", "EPINAL", NULL, NULL, NULL, NULL, NULL, NULL, NULL) ON DUPLICATE KEY UPDATE rue = "2 rue des souris", code_postal = "88000", ville = "EPINAL" /*etc...*/;

---

Par ailleurs, je préconise de mettre les noms de colonne dans le INSERT :

Code:

---

1 2	INSERT INTO deposant (nom,prenom,rue,code_postal,ville,etc) VALUES("VIARD", "Karine", "2 rue des souris", "88000", "EPINAL", NULL, NULL, NULL, NULL, NULL, NULL, NULL) ON DUPLICATE KEY UPDATE rue = "2 rue des souris", code_postal = "88000", ville = "EPINAL" /*etc...*/;

---

Citation:

---

Envoyé par Dendrite

Je pose que ta première colonne est auto-increment.

---

De ce fait, inutile de traiter cette colonne dans le INSERT ; en plus, tu mets NULL dans une clé primaire...

Citation:

---

Envoyé par Dendrite

Je travaille dans une boîte de 1000 "collaborateurs" et nous avons un doublon de ce type

---

Il y a un certain nombre d'années (une trentaine), je travaillais dans une boîte de 500 personnes, et y avait 2 Maurice MARTIN...

Citation:

---

Envoyé par Dendrite

En PHP via PDO, c'est tout à fait possible aussi, avec cette méthode :...

---

L'utilisation du try/catch en PHP, bien !

Citation:

---

Envoyé par Gluups

Arrive-t-il que le client formule un commentaire sur le prix ?
En arrivant, n'a-t-il pas parfois une petite idée de combien il aimerait bien tirer de ses articles, quitte à être déçu ensuite ?

---

OUI, cela arrive la nous en tenons compte le faisons dans la foulée. il arrive aussi qu'il nous demande un avis de prix de vente donc la pareil la question est posé a l'ensemble de l'équipe quel prix pour ce beau livre. si le client est daccord cela est traité directement devant le client pose de l'étiquette code+prix.

Citation:

---

Notre client est arrivé avec trois livres, dont un à trois euros, un à quatre euros cinquante, et un à quarante-huit euros. Mais ces prix ont été définis le lendemain du dépôt.
Il peut aussi être arrivé avec cinq CD, ayant chacun son prix.
C'est bien ça ?

---

Oui si le client nous indique le prix de ces articles nous respectons ça décision bien entendus.

Citation:

---

Envoyé par Dendrite

Bonjour, je reviens sur ton premier post, pour voir si tu peux faire évoluer ton appli selon le moins-disant, puisque c'est ton besoin.
1) Je pose que ta première colonne est auto-increment.
2) Je pose que ta clé d'unicité (indispensable pour définir les doublons qu'on ne veut pas voir) est posée sur un couple de 2 colonnes : nom + prenom.

---

la table " déposant" as eu un petit changement depuis: PRIMARY KEY (`Id_client`), UNIQUE KEY `code_deposant` (`code_deposant`) je n'ai pas mis les autre champs qui eux sont resté les même.

Du coup, avec l'ajout du champ Id_client, j'ai pus modifier le code et crée une page php qui affiche la table déposant, Id_client, code_deposant,,bla,bla,bla.. On indique le N° Id_client voulus pour la recherche d'un ancien client pour vérifier si ces coordonnées sont toujours les même, ainsi dans le formulaire suivant les modifications peuvent être faites sur tout les champs SAUF ID_client.

Citation:

---

Envoyé par Gluups

Deux lettres et le prix de vente, pour le code client ?
Aïe ! J'aurais plutôt deviné qu'on enregistrait :

• un code client, de deux lettres
• un prix de vente

---

En essayant de réécrire les règles de gestion, j'ai la même surprise que Gluups. Ca n'a aucun sens de mettre le prix de vente dans le code client...

bon je vais modifier le sens de la phrase. Car je le redit le prix n'est pas enregistré dans la bdd.

Je pense avoir tenue compte de vos directives. Le MCd est incomplet, concernant les différentes liaisons avec clefs les étrangères , mais déjà es ce que cela vous parait cohérent.:oops:
Pièce jointe 646141

Une association à 4 "pattes" comme (Asso 1) ici, est rarement justifiée.

EDIT : quelles sont les règles de gestion parmi celles fournies le 1er novembre qui ont conduit à un tel modèle ? Je ne vois rien en ce sens

Citation:

---

Envoyé par escartefigue

quelles sont les règles de gestion parmi celles fournies le 1er novembre qui ont conduit à un tel modèle ? Je ne vois rien en ce sens

---

Je m'étais fait la même réflexion en lisant le post de Djockey...Avant d'attaquer le MCD, je pense qu'il faut établir (et valider) les règles de gestion.

Et ça ?

Citation:

---

Envoyé par Djockey

bon je vais modifier le sens de la phrase. Car je le redis le prix n'est pas enregistré dans la bdd.

---

Bonjour,

Dans votre liste ci-dessous, tout n'est pas règle de gestion, de plus, ce ne sont pas les règles "du soft" qui nous intéressent, mais bien celles de votre vie réelle d'association

Citation:

---

Envoyé par Djockey

G
Les régles 5, 6, 7 sont modifiées.

Règles de gestion du soft, pour une bourse aux livres.
1. Les différents statuts des codes clients (on va dire comme cela) : Déposant, ou Bénévoles, et Association.
2. Le code ZZ sera seul ayant le statut Association.
3. Le jour de la vente l’organisateur de la vente donc l’Association retiens 15% sur le prix de vente affiché sur l’article.
4. La retenue de 15% ne s’applique pas au statut bénévole et Association.
5. Un code client, de deux lettres.
un prix de vente (inscrit ultérieurement en général non enregistré dans la bdd).
6. Les articles déposés se répartissent en quatre catégories : Livres, DVD, CD, Vinyl. Nul besoin d’information supplémentaire ce n’est pas type bibliothèque.
7. Le prix de vente n’est pas enregistré c’est dû au fait que le control pour valider la qualité général, le nombre d’articles se fait quelques heure plus tard, voir jour (fastidieux pour les petites mains et du temps).
8. Les articles mis en vente peuvent avoir un état : Déposé (pour être vendus), Invendable (suite au control avant la mise en vente), et vendus.
9. Un client arrive pour déposer ces différents articles un jour XX plusieurs jour avant la vente, on Lui donne un code à deux lettres, on enregistre le Code, Nom, Prénom, Adresse, Cp, Ville, Tél, Email, nombre Livres, nombre DVD, nombre CD, nombre Vinyl.
10. Sur chaque article on appose une étiquette autocollante ou est inscrit le code à deux lettres du client et le prix de vente.
Le jour de la vente :
11. Un acheteur, passe en caisse on registre le code et le prix des articles le type d’article cela doit afficher le nombre total d’articles acheté, le nombre d’articles pour chaque catégorie avec leur prix respectif, la somme total à régler.
12. Possibilité d’annuler un article en cas d’erreur d’enregistrement a la caisse.
13. Possibilité d’avoir une facture avec la liste et prix des articles et la somme payé les coordonnées de l’association, entrer les différentes informations de l’acheteur qui sont : Nom, Prénom, Raison sociale, Rue, Cp, Ville, tel, email.
14. On enregistre la facture afin de pouvoir la retrouvée ultérieurement.
15. A la fin de la vente : On doit connaitre le nombre et type d’articles vendus, et invendus pour chaque client déposant.
16. La somme qui revient au client déposant.

---

De ce qui précède, je reformule ce qui pourrait être un début de liste de règles de gestion

R001 : les personnes déposantes sont des personnes physiques (particuliers ou bénévoles d'associations) ou des personnes morales (associations)

R002a : une personne peut déposer zéro à plusieurs documents
R002b : un document est déposé par une et une seule personne

R003a : une personne peut acheter zéro à plusieurs documents
R003b : un document peut être acheté par au plus une personne

R004a : un document est d'un et un seul type (livre, CD, DVD, vinyl)
R004b : un type peut correspondra à plusieurs documents

Les personnes morales n'ont ni nom, ni prénom, mais elles ont un code SIRET pour les entreprises, d'où l'intérêt dans le modèle ci-dessous de faire des sous-types de personnes en utilisant l'héritage.
Par ailleurs, quand une association dépose des documents, c'est évidemment un représentant de l'asso qui fait l'action, par exemple son président.
D'où la modélisation d'une entité-type [ROLE] ci-dessous pour savoir à quel titre telle personne dépose des documents pour une asso.

Voici donc une ébauche de MCD qui peut vous servir de base de réflexion :

Pièce jointe 646246

Excellent escartefigue car vous avez fait ce que j'avais pour idée de faire sauf qui y avait toujours un truc plus urgent à faire...

Néanmoins, vous proposez un MCD sans donner de façon exhaustive les règles de gestion. J'ai donc quelques questions (même sur les règles que vous donnez) :

1-

Citation:

---

R004b : un type peut correspondre à plusieurs documents

---

j'imagine que c'est ce qui se traduit par la cardinalité 0-n de TC_type_doc vers DC_document ?

2- Asso 5, on ne la renomme pas "appartient à" ?

3- Dans l'association RP_representer, pouvez-vous donner le sens des 2 attributs (je ne vois pas ce qu'un particulier va représenter) ni quel rôle (entité RL_rôle) il aura ?

Autant, rappeler à Djockey la méthode de nommage des entités et des propriétés que vous avez l'habitude (bonne) d'utiliser : les entités sont préfixées par 2 lettres qui rappellent le nom de l'entité et chaque propriété de l'entité possède le même préfixe.

Citation:

---

Envoyé par laurentSc

1- j'imagine que c'est ce qui se traduit par la cardinalité 0-n de TC_type_doc vers DC_document ?

---

Tout à fait, "peut" se traduit en cardinalité minimale de zéro et "plusieurs" par une cardinalité maximale de n

Citation:

---

Envoyé par laurentSc

2- Asso 5, on ne la renomme pas "appartient à" ?

---

Les associations dont l'une des pattes a une cardinalité maximale de "1" ne deviennent pas des tables (sauf si on en fait la demande explicite). Ce faisant, il n'est pas nécessaire de les nommer
Toutefois, c'est quand même préférable, car le MCD est ainsi plus clair. C'est un simple oubli de ma part, j'ai fait ce MCD rapidement.
Néanmoins, plutôt que de la nommer "appartient à", je préfère, et c'est d'ailleurs l'usage, un verbe à l'infinitif ou au participe passé, donc "appartenir" est préférable ;)

Citation:

---

Envoyé par laurentSc

3- Dans l'association RP_representer, pouvez-vous donner le sens des 2 attributs (je ne vois pas ce qu'un particulier va représenter) ni quel rôle (entité RL_rôle) il aura ?

---

On peut imaginer que telle personne est présidente ou trésorière de telle association de telle date de début à telle date de fin, c'est le sens de ces deux attributs.
Mais inutile de s'attarder sur ces points de détail pour l'instant

Citation:

---

Envoyé par laurentSc

Autant, rappeler à Djockey la méthode de nommage des entités et des propriétés que vous avez l'habitude (bonne) d'utiliser : les entités sont préfixées par 2 lettres qui rappellent le nom de l'entité et chaque propriété de l'entité possède le même préfixe.

---

Oui, j'aime bien cette codification qui facilite les études d'impact et évite de tomber sur des noms réservés SQL. Le préfixe peut comporter plus de deux lettres si nécessaire. C'est souvent le cas avec un modèle un peu plus étoffé. Le plus souvent, 3 lettres suffisent.

Oh la la, ça fait un bout de temps que je ne suis pas venu, et du coup il s'est dit pas mal de choses. Moi qui croyais avoir loupé un message ou deux ...

Je crois qu'il va falloir que je réserve une bonne heure pour répondre plus sérieusement. Ça se peut que ce soit Jeudi.

Certains usages sont des adaptations, peut-être variables au fil du temps. J'ai appris Merise il y a un peu plus de 30 ans, et là on exprimait les relations par des verbes à la troisième personne du singulier, de l'indicatif présent. La relation la plus courante était donc "appartient à", mais c'est un mauvais exemple car là on peut mettre le symbole ∈. La relation s'applique de gauche à droite ou de haut en bas. Il est donc déconseillé de disposer les objets de façon Sud-Ouest / Nord-Est, ce qui créerait une ambiguïté.

Et j'avais effectivement coutume de préfixer de trois lettres les noms des champs.

Mais surtout, le plus important, de n'accorder aucune attention à ces points avant d'avoir bien validé le MCD avec l'utilisateur, sachant que c'est l'utilisateur et ses données qui sont importants, pas les grilles dans lesquelles on va les faire entrer plus tard pour que l'ordinateur puisse les voir.

Citation:

---

Envoyé par laurentSc

En essayant de réécrire les règles de gestion, j'ai la même surprise que Gluups. Ca n'a aucun sens de mettre le prix de vente dans le code client...

---

Pour être franc j'ai été un peu taquin, car j'ai pensé que sa langue avait fourché.

Mais en pareille occasion c'est toujours bon d'avoir une occasion de se reprendre, car une ambiguïté, ce n'est pas quelque chose à découvrir à la fin du développement, quand on est en train de déballer les supports de déploiement.

Citation:

---

Envoyé par Djockey

bon je vais modifier le sens de la phrase. Car je le redit le prix n'est pas enregistré dans la bdd.

---

OK je prends bonne note, l'utilisateur écrira le prix au crayon sur l'étiquette.

Bonjour,

Déjà merci à tous pour votre implication. Vus que c’était les congé pour certains, j'attendais patiemment...(j'y suis depuis 31/12/22).

Pour escartefigue Déjà merci
Je pensais bien faire, en détaillant l'utilisation du soft.:oops: Donc j'ai repris les règles dont je me suis grandement inspiré à 90%, je comprend mieux maintenant la demande des règles de gestion.

Pour Gluups quand à moi j'ai découvert Merise grâce a vous, donc quelques jours, donc Looping aussi, et les 15% servent a cela aussi pour l'usure du stylo à bille:mouarf:

Pour laurentSc j'ai lus ça quelque par sur le net, mais je voyais pas trop quoi mettre et si il valait mieux qu'il soit devant ou derrière le nom du champ du coup abandonné, en attendant l'avis de personne plus expérimenté.

Les règles :
R001 : les personnes déposantes sont des personnes physiques (particuliers ou bénévoles de d'association) ou des personnes morales (associations)
R001B : l'association dépose en son nom propre (d'où le statut Association avec un code attribué Spécifique ZZ)
R001C: l'association à un seul unique identifiant (Id_client et code_client dans le shéma post #90)
R001D : Une personne physique à un seul et unique identifiant (code_client post #90)

R002a : une personne physique peut déposer quatre types de documents de zéro à plusieurs documents (100 maxi au total).
R002b : un document est déposé par une et une seule personne.

R003a : une personne peut acheter zéro à plusieurs documents.
R003b : un document peut être acheté par au plus une personne.

R004a : un document peux être de quatre type différents.
R004b: un document ne peux être que d’un seul type à la fois.
R004c : un type peut correspondra à plusieurs documents.

R005a : une personne peut demander une facture
R005b : une personne physique ou morale peur redemander une facture en cas de perte en N+1.

Concernant une ou des personnes morale n'ont ni nom, ni prénom, mais elles ont un seul et unique code Id_client et Code_client (à ce jour Id_client 1, et code_client ZZ).

Ps : pour des raisons purement pratiques et gestion de temps et physique les articles appartenant a l’association le code_client seras toujours ZZ (sinon on embauche 7000 articles a reprendre).

Bonjour,
j'ai pas passé beaucoup de temps sur ces règles donc je sais pas si c'est exhaustif et notamment si elles permettraient de générer le MCD proposé par escartefigue post #93 (j'en doute), mais j'ai quelques questions et/ou remarques :

Citation:

---

R001C: l'association à un seul unique identifiant (Id_client et code_client dans le schéma post #90)

---

quelle est la différence entre Id_client et code_client ? (y a pas un doublon ?)

Citation:

---

R004c : un type peut correspondre à plusieurs documents.

---

pas clair.

Citation:

---

R004a : un document peux être de quatre type différents

---

il faudrait les lister.

Citation:

---

R005b : une personne physique ou morale peut redemander une facture en cas de perte en N+1.

---

N+1, c'est quoi ?