Как установить таблицу клиентов с несколькими телефонными номерами?- Дизайн реляционной базы данных - PullRequest
Новая
       12

Как установить таблицу клиентов с несколькими телефонными номерами?- Дизайн реляционной базы данных

4 голосов
/ 08 апреля 2010 
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
.
.
.
);

Клиент может иметь несколько телефонных номеров, например, Клетка, Работа и др. phoneID в таблице Customer уникален и указывает на PhoneID в таблице Phone. Если запись клиента удалена, также необходимо удалить идентификатор телефона в таблице «Телефон».

Есть ли у вас какие-либо проблемы с моим дизайном? Это разработано правильно? Моя проблема phoneID в таблице Customer является дочерним, и если дочерняя запись удаляется, то я невозможно удалить родительскую (телефонную) запись автоматически.

Ответы [ 2 ]

11 голосов
/ 08 апреля 2010

Я думаю, вы переоценили это. Я не вижу смысла в отдельной таблице Phone + PhoneDetail. Обычно есть два практических подхода.

1) Простота - Поместите все телефоны в саму запись клиента. Да, он нарушает правила нормализации, но на практике он очень прост и обычно работает до тех пор, пока вы его предоставляете (работа, дом, мобильный телефон, факс, экстренная помощь). Перевернутый код - это просто написать, время на реализацию короче. Извлечь все телефоны с записями о клиентах просто, как и при использовании телефона определенного типа (Customer.Fax).

Недостатки : добавление дополнительных типов телефонов позже является более болезненным, а поиск телефонных номеров - глупым. Вы должны написать SQL как "select * from customer where cell = ? or home = ? or work = ? or emergency = ?". Оцените свой дизайн заранее. Если какой-либо из этих вопросов вызывает озабоченность, или вы не знаете, может ли это быть проблемой, воспользуйтесь нормализованным подходом.

2) Расширяемость - Пройдите по маршруту, по которому вы идете. Типы телефонов могут быть добавлены позже, без изменений DDL. Клиент -> Клиент Телефон 

Customer (
   customerId
)

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

PhoneTypes (
   phoneTypeId   (H, W, M, F, etc.)
   phoneTypeDescription
)
1 голос
/ 08 апреля 2010

Поскольку mrjoltcola уже рассмотрела вопрос нормализации, я буду решать проблему наличия записи в телефоне и отсутствия записи в деталях телефона.

Если это ваша единственная проблема, есть три подхода:

1) не удалять из таблицы подробностей, а из телефона с CASCADE DELETE - дает удаление из двух таблиц с одним оператором SQL и сохраняетсогласованные данные

2) имеют триггеры в таблице сведений, которые будут автоматически удалять родительский элемент при удалении последней записи для родительского элемента из дочернего элемента (это не будет работать должным образом и замедлит все удаления в таблице.)это уродливо. все же возможно это сделать)

3) сделать это на уровне бизнес-логики приложения - если этот уровень должным образом отделен и если пользователи (приложения) будут изменять данные только через этослой вы можете достичь желаемого уровня гарантии согласованности

...