bah j'ai deux champ

cli_adr
cli_adr_liv

je ferais choisir à la commande l'adresse de facturation et l'adresse de livraison nan ? si les adresses sont les mêmes je ne fais remplir que cli_adr

marcherait pas ?

si, ça marcherait, mais en mettant plutôt un champ dans la relation COMMANDER, tu évites un champ avec une valeur NULL dans la table client

ok ok je vois ce que tu veux dire merci cyrano

À la rigueur, le num_tel étant unique, il pourrait servir de clé primaire.

Quand compose un numéro, tu es sur de savoir exactement sur qui tu vas tomber ?

À la rigueur, le num_tel étant unique, il pourrait servir de clé primaire.

Quand compose un numéro, tu es sur de savoir exactement sur qui tu vas tomber ?

Quel rapport pjl ?
Un client peut avoir plusieurs numéros : si un numéro est identifié comme "bureau", tu as des chances de tomber sur la réceptioniste par exemple: où est le problème ?

Ca veut simplement dire que la réceptioniste peut être un client, de même que la secrétaire ou le big boss et qu'à la maison, le père ou le fils ainé peuvent aussi être clients.

Tu n'identifies pas le client pas son numéro de téléphone pour deux raison:
- 1 - il peut avoir plusieurs numéros de différents types;
- 1 - S'il change de numéro en déménageant, ça voudrait dire que tu perds le client.

Tu identifie le téléphone PAR le client et non l'inverse. C'est le client que tu appelles, pas son téléphone qui n'a du reste rien à raconter d'intéressant à part de bip bip bip tûûûûûûûût

On est du même avis, simplement, j'ai cru en lisant le post ci-dessous que tu voullais utiliser le n° de tel comme clef primaire pour la table client.

si on pousse un poil plus loin, j'aurais rajouté une entité "telephone" à coté de client avec en propriétés :
- id_tel Int auto_increment <PK>
- num_tel varchar(10)
- type_tel enum('domicile','portable','bureau','fax')
Mais à part parce qu'un client peut avoir plusieurs numéros. et le numéro en varchar parce que sinon le zéro initial sera bouffé à l'enregistrement.

À la rigueur, le num_tel étant unique, il pourrait servir de clé primaire.

Donc, perso, je laisserai le/les tel(s) dans la table client pour une raison toute simple.
Tu rattaches un client à un tel donné.
Le client change de tel, que fais-tu ?
- tu modifies le tel stocké ? et si un autre client a le même tel ?
- tu crées un nouveau tel ?
Ca signifie qu'avant de toucher à ce tel, tu dois vérifier que personne d'autre ne le possède,
si oui, je modifie,
si non, je crée un nouveau tel.
Je trouve que c'est compliquer inutilement la gestion de la base.

Tu la simplifie au contraire. Pourquoi séparer le téléphone du client : parce qu'un client aura un seul numéro, un autre en aura trois: comment vas-tu concevoir la table client ? tandis qu'avec une table téléphone, un client a autant de numéro que nécessaire, 1 ou 25, c'est pareil. Dans la table téléphone, j'ai l'id_client en clé étrangère et je n'ai pas de valeur NULL dans la table client. En plus, ça me permet d'identifier un type de téléphone, domicile, portable, bureau, fax, maison de campagne, ce que tu veux, on peut rajouter éventuellement un nouveau type si besoin est, ça ne change rien à la structure.

Il ne faut pas non plus se prendre la tête.
Dans l'absolu, oui, on peut gérer x n° de tel pour un client mais dans la pratique..............
Regarde ce que font les sociétés de vente par correspondance, la redoute par exemple. Il y a trois tels

Mon téléphone domicile : *(ex:0102030405)

Mon téléphone au travail: *Numéro de poste : *

Mon téléphone mobile :

CDiscount : 2 tels.

et je suis certain à 99% qu'ils ont une table réservée à ça: quand tu conçoit une base de donnée, il faut aussi souvent que possible éviter les valeurs NULL. Si tu mets des champs téléphones dans la table client, avec un seul téléphone, tu as deux valeurs NULL, place perdue pour rien qu'on peut retrouver à de multiples lignes: sur une base de 250 000 clients, imagines la place que ça occupe pour rien ?