Дизайн базы данных, как нормализовать?

Question

В настоящее время я борется с созданием правильного дизайна схемы базы данных для моего проекта. Позвольте мне представить таблицы:

tblOrder

id 
executive_id 
supervisor_id 
client_id 
building_id? 

tblexecutive

executive_id 
address_id 

tblsupervisor

supervisor_id 
address_id 

tblclient

client_id 
address_id 

tbladdress

generic information, e.g location phone fax 

Не уверен, что это:

tblbuilding

building_id 
address_id 
(or address information here) 

Это выглядит вполне нормализованным для меня. Но клиент дает здание, в котором выполняется заказ, который также связан с адресом. Правильно ли ссылаться на таблицу адресов или создавать новую таблицу зданий с адресами или добавлять новое поле таблицы адресов, например. isOrderBuilding (bool)?

Answer 1

Ну, в реальном мире здание может иметь более одного адреса. Подумайте о углах зданий, у них есть 2 адреса. Что делать, если здание настолько велико, что оно закрывает дырокол? Для этого требуется 4 разных адреса для одного здания. Чтобы справиться с этим, я хотел бы предложить иметь идентификатор здания в вашей адресной таблице, чтобы каждый адрес ссылался на одно здание, но любое здание могло иметь несколько адресов.

Однако вполне возможно, что в вашем проекте это не нужно, и для каждого здания достаточно одного адреса. Если это так, я предлагаю хранить здания и адреса в одном столе.

В любом случае, для самого адреса я предлагаю разбить его как минимум на 3 таблицы: Таблица городов, таблица улиц и таблица адресов (с соответствующими отношениями). Кроме того, вы можете пойти еще глубже и создать таблицу отношений Streets To Cities и вместо этого иметь таблицу Address, относящуюся к этой таблице. Это не позволит вам указывать адреса на улицах, которые не принадлежат городу этого адреса.

Опять же, все это зависит от потребностей проекта. мое последнее предложение, вероятно, является излишним, если это всего лишь школьный проект, но если это для коммерческого программного обеспечения, я бы определенно его использовал.