question conseil

par **Cyrano** » 05 mai 2005, 22:34

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 ?

par **pjl** » 05 mai 2005, 22:30

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.

par **Cyrano** » 05 mai 2005, 22:15

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.

par **pjl** » 05 mai 2005, 22:10

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.

par **Cyrano** » 05 mai 2005, 18:22

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

par **pjl** » 05 mai 2005, 17:58

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.

par **Cyrano** » 05 mai 2005, 17:53

À 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 ?

par **pjl** » 05 mai 2005, 17:41

À 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 ?

par **beta** » 05 mai 2005, 16:06

ok ok je vois ce que tu veux dire merci cyrano

par **Cyrano** » 05 mai 2005, 15:44

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

par **beta** » 05 mai 2005, 15:32

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 ?

par **Cyrano** » 05 mai 2005, 15:22

Ha si tiens, il manque encore un truc: comment vas-tu déterminer que le client est celui à qui on facture ou celui à qui on expédie la commande ?

Première idée : un champ enum dans la relation "Commander"

par be » 05 mai 2005, 15:15

exact le numéro de tél :/ mouarf les truc basiques je l'ai oublie ! c'est dingue ça !

par **Cyrano** » 05 mai 2005, 15:12

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.

par **beta** » 05 mai 2005, 15:05

lol cyrano

bah oué au final ça revient au mm je peux en effet mettre date dans commander et le rendre obligatoire

rien d'autre à signaler par hasard ?

question conseil

Répondre

Étendre la vue Revue du sujet : question conseil