Discussion :

[Tortille]

Bonjour le forum,

Dans le contexte de la location saisonnière, ma table "T_Client" contient les champs [Civilite], [Nom] et [Prenom].

Je note dans ces champs si le client est seul :
[Civilite] : (M.),(Mme)
[Nom] : (Le nom de la personne)
[Prenom] : (Le prénom de la personne)

Si le client n'est pas seul :
[Civilite] : (M. et Mme), (MM.) ou (Mmes)
[Nom] : (Le nom de Monsieur "-" le nom de Madame), (Le nom de Monsieur1 "-" Le nom de Monsieur2) ou (Le nom de Madame1"-" Le nom de Madame2)
[Prenom] : (Le prénom de Monsieur "Et" le prénom de Madame), (Le prénom de Monsieur1 "Et" le prénom de Monsieur2) ou (Le prénom de Madame1"Et" le prénom de Madame2)

Je voudrais savoir comment faire pour gérer les clients individuellement lorsque le client n'est pas seul, en conservant les associations la table "T_Client".

Merci d'avance pour vos idées.

[f-leb]

Bonsoir,

Quelque chose comme ça :


T_accompagner :

idClient	idClientAccompagnant
1	2
1	3

Le client 1 est accompagné des clients 2 et 3.

[Tortille]

Bonjour f-leb,
merci pour cette idée, je vais commencer comme ça, mais ne faudrait-il pas adjoindre les réciproques :
Le client 2 est accompagné des clients 1 et 3 et
Le client 3 est accompagné des clients 1 et 2.

Et dans ce cas je me retrouve avec 3 groupes (identiques pour un humain)
Le client 1 est accompagné des clients 2 et 3
Le client 2 est accompagné des clients 1 et 3
Le client 3 est accompagné des clients 1 et 2

Simple constatation; alors que l'humain comprend avec une ligne,
la machine en demande 6 dans la table "T_accompagner" pour le même résultat :
1 accompagne 2
1 accompagne 3
2 accompagne 1
2 accompagne 3
3 accompagne 1
3 accompagne 2

Il faudrait aussi différencier les séjours, donc adjoindre un "IdRes" (numéro de réservation) à la table "T_accompagner" car si l'année suivante Le client 1 est accompagné des clients 2 et 4 , il ne faut pas que ça se mélange avec l'année précédente.

Actuellement je ne gère pas les enfants, mêmes majeurs, ils sont simplement notés dans le champs [notes] "T_Client" et dans l'[effectif] de la "T_Reservation" donc je suis dans 99% des cas dans le cas du "client 1 accompagne client 2" et réciproque"client 2 accompagne client 1". (humain 1, machine 2)
Il n'y a pas d' "IdRes" dans ma table "T_Client", mais un "IdCli" dans ma table "T_Reservation"

Les cas les plus courants sont :
cas 1/ Monsieur 1 accompagne Madame 1 puis avec le temps Monsieur 1 accompagne Madame 2
Dans ma table "T_Client" j'ai donc pour ce cas 2 clients nommés :
- "Monsieur 1 et Madame 1"
- "Monsieur 1 et Madame 2"
mais je n'ai pas de client nommé "Monsieur 1" ni "Madame 1" ni "Madame 2"

cas 2/ Monsieur 1 accompagne Madame 1 puis Madame 1 vient seule
Dans ma table "T_Client" j'ai donc pour ce cas 2 clients nommés :
- "Monsieur 1 et Madame 1"
- "Madame 1"
mais je n'ai pas de client nommé "Monsieur 1"

Dans ma configuration je ne peux pas savoir combien de fois est venu "Monsieur 1" ni "Madame 1" à cause des homonymes à moins d'adjoindre un numéro de tél. ou un E-mail à ces noms mais il faudrait qu'ils n'en aient point changé (dans le cas 2 les Dames changent souvent ces info.).

Je commence à voir que ça va être compliqué :
j'aurais
- des clients d'une personne et
- des groupes de clients de 2 ou plusieurs personnes faits de 2 ou plusieurs clients d'une personne.
la question est où je mets l'adresse et les autres infos client ?

Dois-je créer les tables "T_Adresses", "T_Tel","T_Email", exemple pour éviter les adresses en double dans les clients "Monsieur 1" et "Madame 1" qui vivent en couple à la même adresse ?

Oh là là, où va-t-on ?

De l'aide s'il vous plait, je me noie ! gloup

[f-leb]

Bonjour,

Les cas les plus courants sont :
cas 1/ Monsieur 1 accompagne Madame 1 puis avec le temps Monsieur 1 accompagne Madame 2...

C'est suspect ton activité de location, mais j'ai sans doute l'esprit mal tourné

Et pourquoi pas un plan d'occupation de la location (table T_occupation) ?

[Tortille]

Bonjour f-leb,
Vous me charriez, mon activité est la location saisonnière, et ces cas sont les cas réels de la vie. Et malheureusement pour moi, combien de familles ont séjourné dans mes locations, puis se sont déchirées et n'ont plus osé revenir. Ça demande du courage de revenir non accompagné ou avec une autre personne sur des lieux chargées de souvenirs.

Sinon pour en revenir à ma demande, votre première réponse cernais mieux le problème.

De ma table "T_Client" qui contient des clients d'une personne, mais aussi des clients en couples donc de 2 personnes, je voudrais une table primaire genre "T_individu" dans laquelle il n'y aurait que des individus d'une personne et d'où je piocherais les noms pour remplir ma table "T_Client" actuelle.
Les complications arrivent avec les infos clients
Dans la table "T_Individu", si je mets les adresses, il y aura des adresses doublons dans le cas des couples, donc il faut une table T_Adresse" reliée à la table "T_Individu", idem pour le tél. , les E-mails ...
pour remplir la table "T_Client, il me faudra faire des requêtes Union puis regroupée sur la table "T_adresse" etc.
Pour constituer les noms de clients en couple de la table "T_Client" il faut que Monsieur soit en premier, c'est important pour les courriers automatiques liée à la location.

C'est compliqué comme ça mais si j'arrive à le mettre en œuvre, ce sera génial à utiliser.
Je vous mets mon avancement dans la base suivante, juste sur la reconstitution des noms de clients en couples dans le bon ordre, et là pour le moment ça foire, car ça recherche par balayage de la liste, si madame est dans la liste en premier le nom commence par Madame, même si j'ai choisi Monsieur en premier.

J'ai mis la table "Copie de T_Client" comme sauvegarde de "T_Client" pour réinitialiser "T_Client" quand ça foire trop.
Pour rajouter un individu à un client, pour le moment il faut être en modification (par la suite il faudra obligatoirement être en création) et cliquer sur le contrôle vert, une nouvelle liste apparait dans laquelle on peut choisir un ou plusieurs individus. on re-clique sur le contrôle vert et la liste d’interverti avec la liste de recherche, le nom et prénom sont constitués de 2 individus ou plus.

Il y a encore beaucoup de travail.

Merci pour votre aide sur ce projet.

[tee_grandbois]

bonjour,

Pour constituer les noms de clients en couple de la table "T_Client" il faut que Monsieur soit en premier,

même si c'est madame qui ramène les sous à la maison ?
Non, pour moi, il faut, comme tout contrat de location définir qui a fait la réservation et donc l'a payé, un point c'est tout. Les autres n'ont rien à voir avec le contrat et ne doivent être considérés que comme des occupants.

[hyperion13]

Salut
J'ai déjà piloté des logiciels de réservation "hôtellerie" , Amadéus et compagnie, les développeurs ne sont pas allés aussi loin dans ce genre de brainstorming. Et on peut les comprendre. Même l'INSEE, dans ses statistiques mensuelles de fréquentation ne va pas aussi loin.
Je me demande pourquoi l'hôtelier aurait besoin de savoir que M. Pierre, qui a réservé et séjourné en N-1 dans son hôtel, et qui était alors accompagné de Mme Paule, réserve en N, mais sera accompagné cette fois-ci de M. Jacques?
Et pour les enfants, vous ne voudriez pas savoir s'ils sont du premier lit ou pas ?
D'ailleurs il suffirait d'aller sur les formulaires de réservation en ligne des établissements hôteliers ou autre pour analyser leur structure. 1 civilité, 1 nom, 1 prénom, 1 adresse postale, num tél, ads mail. Je n'ai jamais vu de champs doublés au prétexte que la réservation est faite pour un couple, marié, pas marié, pacsé, etc.
Et pour compléter, pourquoi pas, l'idée de schéma du Post#4 de f_leb, que je salue au passage, on pourrait ajouter dans la pseudo-entité les attributs nombre d'adultes, d'enfants, de maitresses et de pets .

Et si c'est Mme qui réserve pour le couple ou son amant, vous faites comment? Vous mettez M. en premier ?

...Pour constituer les noms de clients en couple de la table "T_Client" il faut que Monsieur soit en premier, c'est important pour les courriers automatiques liée à la location.

[f-leb]

Vous me charriez,...

meuh non, à peine..

Comme le besoin s'éclaircit, je fais une deuxième proposition :



Un client peut avoir plusieurs coordonnées (parce qu'il peut déménager par exemple) mais on conserve une date d'enregistrement de ses coordonnées (DateEnrCoordonnees), ce qui permet de retrouver ses dernières coordonnées. D'ailleurs un client peut ne pas avoir de coordonnées (un simple accompagnant que tu n'as pas besoin de joindre).

Lors d'une location, tu enregistres le client qui fait la réservation (idClientReservation). Tu enregistres aussi les coordonnées en cours au moment de la location (idCoordonneesFacturation pour la facturation par exemple).
Avec la table T_accompagner, tu peux indiquer les éventuels accompagnants.

[Tortille]

Bonsoir,
pour répondre dans le désordre:
- Les bases INSEE sont truffées de doublons, ce n'est pas une référence.
- Voir ce que les autres fond ne m'intéresse pas, ces grands groupes n'existaient pas que je louais depuis belle lurette.
- Je ne loue plus qu'a la quinzaine, est-ce que les grands groupes font ça ?
- le nombre d'adultes, enfants, de de bébés sont notés dans la Table "T_Reservation", c'est plus pour connaître l'effectif parce que les enfants au bout des années deviennent adultes mais ils restent les enfants de leurs parents. Oui alors comment je les note ? en adulte !
- Quand un couple (j'ai mal utilisé le mot "couple", j'entends "couple" comme couple de personnes mariées) loue une de mes locations, je lui adresse des courriers automatiques où l'adresse commence par Monsieur, donc dans le Nom du client je suis obligé d'avoir le nom de Monsieur en premier. Si les personnes ne sont pas en couple et que c'est madame qui loue et que je n'ai pas le nom de monsieur, ce sera au nom de Madame.
- sinon il faut un casque pour "piloter" des logiciels de réservation "hôtellerie", ça doit bomber ce truc là. Sérieux y-a des courses ? Je suis dans les locations saisonnières, c'est bien différent je ne loue pas de chambre mais des maisons. Oui elles ont aussi des chambres mes maisons. Ah ! Tu piges ou je repends ? excuse, mais c'est la mode de charrier.
- La modif que je cherche à apporter à cette table par ce post est un peu de travail par rapport au gain qui en sortira mais bon pourquoi pas. ça pousse un peut loin le bouchon, pour un développeur c'est pas rentable.

Pour toute aides constructives, dans la dernière base que j'ai mis, je me sert du champs texte [xIdCli] pour inscrire les id des clients qui constituent les couples. Il me reste à trouver le moyen de les ordonner, soit par analyse des civilités, soit par la saisie genre: si Monsieur, le saisir en premier. Pour le moment, j'explore la méthode par la saisie, et elle me résiste fermement. Mais j'ai pas dit mon dernier mot, aussi pour vous, toutes les pistes sont les bien venues pour briser la résistance.

J'utilise déjà cette fonctionnalité dans les assurances de mes locations mais sans chercher à ordonner les biens assurés :
Suivant les contrats que je souscris, l'assureur assure un, 2 ou 3 biens sur le même contrat alors que les années précédentes ces biens étaient assurées indépendamment chez un autre assureur. Vous voyez la similitude, une table "T_Logement" et des assurances qui assurent des "couples" de logements.
Quant à assurer, pourquoi pas ajouter les assurances véhicules, ce serait idem pour les flottes de véhicules. Après rassurez-vous, aucun assureur ne m'a encore assuré le couple logement-véhicule, il faut aussi dire qu'ils ne plaisantent pas les assureurs, ils sont même un peu vieux jeu.

Pour f-leb,

Dans ma demande je ne veux toucher qu'à la table "T_Client", lui adjoindre les tables "T_ClientCoordonnee" et "T_Coordonnee" ça c'est bon.
Mais comme la gestion du planning est directement impactée par la table "T_Client" je ne peux pas tout chambouler.
En ce moment j'explore la piste de la table "T_Client" qui crée les couples avec des Clients seuls de la table "T_Client" par le champs texte [xIdCli], un genre de champ multi-valué qui garde la provenance du Client Couple.

Je mets les relations de ma base. Il n'y a que les champs en relation pour la place sur l'écran.Pièce jointe 623681
Et doucement les critiques, c'est du véritable Tortille tricoté à la main. (garanti inusable)

à bientôt

[f-leb]

Bonsoir,

Pour gérer les couples, et sans toucher à la table T_clients, je propose ceci :


Et si le client 2 est en couple avec le client 3, inutile de renseigner que le client 3 est en couple avec le client 2.

Le reste n'est que du traitement avec des requêtes.

Pour rechercher le conjoint d'un client :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT T_en_couple.idClientConjoint
FROM T_en_couple 
WHERE T_en_couple.idClient = [idClient ?]
   UNION
SELECT T_en_couple.idClient
FROM T_en_couple
WHERE T_en_couple.idClintConjoint = [idClient ?];

Pour lister tous les clients en couple :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT T_Client.idClient FROM T_Client INNER JOIN T_en_couple ON T_Client.idClient = T_en_couple.idClient
UNION 
SELECT T_Client.idClient FROM T_Client INNER JOIN T_en_couple ON T_Client.idClient = T_en_couple.idClientConjoint;

Je mets une démo en pièce jointe.

PS : il semble que ta pièce jointe soit jugée "invalide" par le forum.

[Tortille]

Bonjour le forum,

Bonjour f-leb
Merci pour cette nouvelle solution
Est ce que je peux remplacer la relation 1-1 par une 1-oo comme dans le post 2
c'est parce que si les couples suivants se séparent
(3,2)
(4,1)
le couple suivant ne peut être constitué
(3,4) création refusée parce qu'on a déjà un 3 en premier
(4,3) création refusée parce qu'on a déjà un 4 en premier

J'ai bien sûr essayé vos requêtes avec la relation 1-oo elles fonctionnent et conservent l'ordre de saisie ce qui est TOP.

Pour la pièce jointe, quand j'ai écris le post, elle s'affichait, c'est une capture impression écran enregistrée dans Paint et rognée avec Microsoft Office 2010 pour un poids de 96Ko.

A bientôt

[f-leb]

Je vois deux choses...

le couple suivant ne peut être constitué
(3,4) création refusée parce qu'on a déjà un 3 en premier
(4,3) création refusée parce qu'on a déjà un 4 en premier

Si 3 est en couple avec 4, il est inutile de renseigner que 4 est en couple avec 3. Ce serait redondant comme information.

c'est parce que si les couples suivants se séparent
(3,2)
le couple suivant ne peut être constitué
(3,4) création refusée parce qu'on a déjà un 3 en premier

Je pensais dans un premier temps qu'une mise à jour suffirait en modifiant la ligne (3, 2) en (3,4), et il faut regarder si 4 n'est pas déjà en couple ailleurs dans la table. Il est vrai que dans ce cas tu perds l'historique, mais est-ce gênant ?

Sinon, la saisie des couples (3,2) et (3,4) est un cas de polygamie

Tu peux aussi rajouter une date d'enregistrement :
T_enCouple(idClient, idClientConjoint, DateEnregistrement). Pour savoir qui est avec qui aujourd'hui, tu recherches à la date la plus récente.

[Tortille]

Bonjour f-leb

Si 3 est en couple avec 4, il est inutile de renseigner que 4 est en couple avec 3. Ce serait redondant comme information.

C'était juste pour te dire que je ne pouvais créer cette union ni dans un sens ni dans l'autre avec la relation 1-1, et j'avais compris que les requêtes n'ont pas besoin de la réciproque.

Je pensais dans un premier temps qu'une mise à jour suffirait en modifiant la ligne (3, 2) en (3,4), et il faut regarder si 4 n'est pas déjà en couple ailleurs dans la table. Il est vrai que dans ce cas tu perds l'historique, mais est-ce gênant ?

Chaque fois que je crée un client, c'est qu'il a une activité genre : "Demande d'info sur une location" ou "réservation", bref ça rend le client non modifiable, du coup si le client vient avec une autre personne "significative" compagne/compagnon ou amie/ami, je suis obligé de créer ce nouveau client composé qui aura sa propre activité.
Le but de post est de savoir l'activité au niveau client individuel, chose qu'il m'est actuellement impossible de savoir. Je n'ai pas de lien entre clients, "Monsieur et Madame" et "Madame" sont actuellement 2 clients différents, alors que c'est la même "Madame" dans ces 2 clients, le regroupement de l'activité au niveau de "Madame" est faux.

"Il est vrai que dans ce cas tu perds l'historique, mais est-ce gênant ?"
Je n'ai pas d'historique sur la table "T_Client".

Tu peux aussi rajouter une date d'enregistrement :
T_enCouple(idClient, idClientConjoint, DateEnregistrement)

Pas besoin de "DateEnregistrement", c'est l'activité dans la table "T_Reservation" qui s'en charge

Pour savoir qui est avec qui aujourd'hui, ...

C'est pas le but du tout.
Mon but est de voir sur le planning que "Madame" est venue 8 fois, quand "Monsieur et Madame" sont venus 5 fois ensemble, puis que "Madame" est venu 3 fois seule.


Sinon,
Au moment où je vous écris, j'ai un nouveau problème qui m'apparait et qui risque de tout faire capoter, je m'explique :
Je crée le client lors de sa première activité qui est généralement une demande d'information
Je réponds à ce client en lui soumettant une offre.
Si le client donne suite il doit m'envoyer ses coordonnées afin d'établir le contrat de location.
Je reçois en coordonnées : M. et Mme Untel Alain et Pascale.
C'est un couple, je modifie dans la table "T_client" la civilité "M. et Mme", le nom "Untel ", prénom "Alain et Pascale"

Dans ma logique je devrais créer les 2 clients "Untel Alain' et "Untel Pascale" au paravent pour créer le client "Untel Alain et Pascale"

L'année suivante ce client a divorcé, madame revient seule dans une location, chouette, javais prévu le coup, j'ai le client "Untel Pascale".
Mais zut, madame à repris son nom de jeune fille "Untel_le Pascale".

Bien sur il est hors de question de modifier le client "Untel Pascale" en le client "Untel_le Pascale".
Donc la création du client "Untel Pascale" ne m'aura servi à rien.

Je retombe sur ma table "T_Client" actuelle avec le client "Untel Alain et Pascale" et le client le client "Untel_le Pascale".

Encore une fois f-leb, je reviens à ta solution simple du post 2 avec la T_accompagner.

A bientôt

[f-leb]

Finalement, ne faudrait-il pas plus simplement :

• une table T_Personne(idPersonne, nom, prenom, ...), une personne étant un client potentiel
• Un client est soit une personne seule, soit une personne avec un conjoint, donc une table T_Client(idClient, #idPersonne, #idPersonneConjoint, ...). Si le client est une personne seule, tu laisses idPersonneConjoint à Null

Et tu relies T_location à T_Client.

[Tortille]

Salut l-feb,

Je vois ce que tu veux dire, c'est une solution pour ce post, mais pas si simple par rapport à ce que je fais actuellement.

Exemple fictif.
En 2015
j'ai M.et Mme Blanc Louis et Marie qui louent.
j’inscris dans la table T_Personne (idPersonne, nom, prenom, ...)
pour Monsieur : 1,Blanc,Louis
pour Madame : 2,Blanc,Marie
je crée le client dans la table T_Client (idClient, #idPersonne, #idPersonneConjoint, ...) je rajoute Nom, Prénom
client 1:
1,1,2,Blanc,Louis et Marie

en 2021
Madame Blanc Marie revient seule (divorce) elle reprend son nom de jeune fille "Brun"
Là j'ai 2 solutions :
1/Je crée le nouveau client à partir de la personne (2,Blanc,Marie) en renommant Blanc en Brun dans la table Client ce qui conserve le lien avec la personne 2
client 2: (oui 2 clients en 6 ans c'est peu)
2,2,Null,Brun,Marie

Bilan 4 enregistrements créés

2/je crée la nouvelle personne dans la table T_Personne (idPersonne, nom, prenom, ...)
3;Brun;Marie
puis je crée le nouveau client et perds le lien avec la personne 2
client 2:
2,3,Null,Brun,Marie

Bilan 5 enregistrements créés

Bilan au mieux 4 enregistrements créés plus la table T_Personne plus lourde que la table T_Client

Comparé à ce que je fais actuellement ci dessous

en 2015
je crée le client dans la table T_Client (idClient,Nom, Prénom)
1,Blanc,Louis et Marie

en 2021
je crée le client dans la table T_Client (idClient,Nom, Prénom)
2,Brun,Marie

Bilan 2 enregistrements créés

Plus ce que je dois faire pour créer le lien:
ajouter la table T_ClientInclus (idClient,idClientInclus) en relation comme votre table T_En_Couple du post 10 mais sans la réciproque,
1,2 : (Brun Marie) est inclus dans (Blanc Louis et Marie)

Bilan 3 enregistrements créés en tout plus la table T_ClientInclus qui ne concernera maxi qu' 1% des clients donc légère.

Laissez moi le temps de mettre ça en œuvre Je vous tiens informé

A bientôt

[f-leb]

en 2021
Madame Blanc Marie revient seule (divorce) elle reprend son nom de jeune fille "Brun"
Là j'ai 2 solutions :
1/Je crée le nouveau client à partir de la personne (2,Blanc,Marie) en renommant Blanc en Brun dans la table Client ce qui conserve le lien avec la personne 2
client 2: (oui 2 clients en 6 ans c'est peu)
2,2,Null,Brun,Marie

Bilan 4 enregistrements créés

2/je crée la nouvelle personne dans la table T_Personne (idPersonne, nom, prenom, ...)
3;Brun;Marie
puis je crée le nouveau client et perds le lien avec la personne 2
client 2:
2,3,Null,Brun,Marie

Bilan 5 enregistrements créés

La solution 1/ est bien meilleure. La personne qui change de nom reste la même personne.
Je rappelle le but :

Mon but est de voir sur le planning que "Madame" est venue 8 fois, quand "Monsieur et Madame" sont venus 5 fois ensemble, puis que "Madame" est venu 3 fois seule.

Avec ta solution 2/, Blanc Marie est venue 1 fois et Brun Marie est venue 1 fois, alors que c'est la même personne qui est venue deux fois. Ce n'est pas ce que tu veux il me semble.

Le nombre d'enregistrements créés ne devrait pas être un critère, sinon il n'y a qu'à mettre toutes les personnes dans le même enregistrement et ce serait encore mieux Nombre de membres ici ont géré des fichiers clients sous Access de dizaines de milliers de personnes, voire quelques centaines de milliers sans broncher...

[Tortille]

Bonsoir l-feb

J'aurais préféré votre avis sur Plus ce que je dois faire pour créer le lien dans

Comparé à ce que je fais actuellement ci dessous

en 2015
je crée le client dans la table T_Client (idClient,Nom, Prénom)
1,Blanc,Louis et Marie

en 2021
je crée le client dans la table T_Client (idClient,Nom, Prénom)
2,Brun,Marie

Bilan 2 enregistrements créés

Plus ce que je dois faire pour créer le lien:
ajouter la table T_ClientInclus (idClient,idClientInclus) en relation comme votre table T_En_Couple du post 10 mais sans la réciproque,
1,2 : (Brun Marie) est inclus dans (Blanc Louis et Marie)

Bilan 3 enregistrements créés en tout plus la table T_ClientInclus qui ne concernera maxi qu' 1% des clients donc légère.

Ajouter la table T_ClientInclus (idClient,idClientInclus), j'y rajoute même le champ [En_tant_que].
Ce qui fait T_ClientInclus (idClient,idClientInclus, EnTantQue) pour Brun Marie :
1,2,Blanc Marie
Ce qui donne :
Dans le client 1, j'ai le client 2 inclus en tant que Blanc Marie
ou plus clairement
Dans M.et Mme Blanc Louis et Marie, j'ai Brun Marie incluse en tant que Blanc Marie
Il y a surement d'autre termes plus appropriés que "Inclus": "Présent" ?

Ce qui devrait me permettre de regrouper l'activité de M.et Mme Blanc Louis et Marie avec celle de Brun Marie

La table T_ClientInclus sera toute petite car ce n'est qu'une poignée de clients qui seront concernés à cause de leur une activité sur plusieurs décennies.

Aujourd'hui j'ai rien pigné (15 août). Il me faut le temps d'essayer, c'est pas si éloigné des solutions des post 2 ou 10.

A bientôt

[f-leb]

Bonjour,

J'aurais préféré votre avis sur Plus ce que je dois faire pour créer le lien dans...

Mon avis est que tu devrais laisser tomber ton idée...

Comparé à ce que je fais actuellement ci dessous

en 2015
je crée le client dans la table T_Client (idClient,Nom, Prénom)
1,Blanc,Louis et Marie

Vouloir faire rentrer deux personnes dans le même enregistrement est, dès le départ, une très mauvaise idée. La suite est une tentative de bricolage pour pallier à cette erreur de conception, une sorte de patch pour essayer de faire comprendre que cet enregistrement concerne deux personnes.

Ton besoin est pourtant très simple, et pour le suivi des clients il suffit d'appliquer le concept encore plus simple :
1 personne avec civilité+nom+prénom = 1 enregistrement

Toutes mes propositions sont allées dans ce sens.

[Tortille]

Bonjour f-leb,

Merci, c'est clair.
Mais ma table T_Client doit rester telle quelle, elle s'adapte à tous les cas de figure rencontrés en 34 ans de location.

Je vais juste trouver un bricolage pour lui faire comprendre que tel client qui vient seul aujourd'hui est le même que l'une des deux personnes qui formaient le client en couple au paravent.

Et reconnaissez que même avec 1 personne = 1 enregistrement le cas de Madame sera dans certains cas du bricolage.
ex Madame Blanc qui revient avec le nom de Madame Brun !

A bientôt

[Tortille]

Bonjour,

Ce que je voulais faire sur la table des clients ne marche pas, il faudrait le porter sur la table des réservations, mais mon architecture ne le permet pas et surtout je n'ai pas les données parce que je ne les ai pas collectées à l'époque (il y a 35 ans).

Le but était juste de savoir combien de fois était venue en location une personne.

Premier problème, contournable par bidouillage, une dame peut venir sous son nom d'épouse ou de jeune fille.

Second problème, rédhibitoire, un couple vient avec ses enfants, 10, 12 et Aldo 16 ans. Dix ans plus tard Aldo s'est marié et vient en location, ses parents prennent aussi une location mais avec une semaine de décalage (il faut garde le chien à la maison, mais là n'est pas le problème).
Donc dans ce cas Aldo est venu 2 fois, ses parents 2 fois, mon idée initiale était d'additionner les 2 séjours des parents et le séjour d'Aldo pour connaitre combien de fois est venu Aldo, et c'est faux, ça donne 3 au lieu de 2 car ses parents sont venus sans Aldo la seconde fois.

Encore une fois dans l'empressement je n'analyse pas assez profondément le problème, jusqu'à présent je m'en suis sorti en modifiant (bidouillant) le code pour faire gober au programme les cas inattendus que les clients "inventent". Là c'est bloqué pour un moment, après c'était pas vital.

Snif Snif

A bientôt