Comment définir une table client avec plusieurs numéros de téléphone? - Conception de base de données relationnelle

Question

CREATE TABLE Phone 
(
phoneID - PK 
. 
. 
. 
); 

CREATE TABLE PhoneDetail 
(
phoneDetailID - PK 
phoneID - FK points to Phone 
phoneTypeID ... 
phoneNumber ... 
. 
. 
. 
); 

CREATE TABLE Customer 
(
customerID - PK 
firstName 
phoneID - Unique FK points to Phone 
. 
. 
. 
); 

Un client peut avoir plusieurs numéros de téléphone, par ex. La cellule, le travail, etc. phoneID dans Customer table est unique et pointe vers PhoneID dans Phone table. Si l'enregistrement du client est supprimé, le paramètre phoneID de la table Téléphone doit également être supprimé.

Avez-vous des problèmes sur ma conception? Est-ce conçu correctement? Le numéro de téléphone dans la table Customer est un enfant et si l'enregistrement enfant est supprimé, alors je ne peux pas supprimer automatiquement l'enregistrement parent (Phone).

Answer 1

Comme mrjoltcola déjà abordé la normalisation, je vais aborder le problème d'avoir un enregistrement dans le téléphone et aucun enregistrement en détail de téléphone.

Si tel est votre seul problème, il existe trois approches:

1) ne supprime pas de la table de détail, mais à partir du téléphone avec CASCADE SUPPRIMER - donne une suppression de deux tables avec une instruction SQL unique et conserve des données cohérentes

2) avoir des déclencheurs sur la table de détails qui supprimera automatiquement le parent lorsque le dernier enregistrement pour un parent est supprimé de l'enfant (cela ne fonctionnera pas bien et ralentira toutes les suppressions sur la table.) Et il est moche. est possible de le faire)

3) le faire dans la couche de la logique métier de la pplication - si cette couche est correctement séparée et si les utilisateurs (applications) modifient les données uniquement à travers cette couche, vous pouvez atteindre le niveau de cohérence souhaité.

Answer 2

Je pense que vous l'avez surdéfinie. Je ne vois aucune utilité pour une table Phone + PhoneDetail séparée. Typiquement, il existe deux approches pratiques.

1) Simplicité -Mettez tous les téléphones du Client dans l'enregistrement. Oui, il enfreint les règles de normalisation, mais c'est très simple dans la pratique et fonctionne habituellement aussi longtemps que vous fournissez (travail, maison, mobile, fax, urgence). Le code Upside est simplement écrit, le temps de mise en œuvre est plus court. La récupération de tous les téléphones avec un enregistrement client est simple, tout comme l'utilisation d'un type de téléphone spécifique (Customer.Fax).

Les inconvénients: l'ajout de types de téléphones supplémentaires plus tard est un peu plus douloureux, et la recherche de numéros de téléphone est kludgy. Vous devez écrire SQL comme "select * from customer where cell = ? or home = ? or work = ? or emergency = ?". Évaluez votre conception à l'avance. Si l'un ou l'autre de ces problèmes est préoccupant, ou si vous ne savez pas si cela peut être préoccupant, adoptez l'approche normalisée.

2) Extensibilité - Suivez la route que vous venez de suivre. Les types de téléphone peuvent être ajoutés plus tard, aucun changement DDL. Client -> CustomerPhone

Customer (
    customerId 
) 

CustomerPhone (
    customerId references Customer(customerId) 
    phoneType references PhoneTypes(phoneTypeId) 
    phoneNumber 
) 

PhoneTypes (
    phoneTypeId (H, W, M, F, etc.) 
    phoneTypeDescription 
)