stenford
Нарушена 3-я нормальная форма, вопрос такой - какие именно аномалии мы уберем, если вынесем подобные сущности в другие таблицы? Ведь по-сути тут связь один к одному.
В реальной предметной области, которую пытается отобразить БД, связь тут все-таки "один ко многим" (у многих клиентов город текущего адреса один и тот же). ИМХО имеет смысл не только вынести в отдельные сущности улицы, города, штаты (области) и т.п. и потратиться на формирование справочников хотя бы из существующих данных, но и выделить адреса вообще в отдельную таблицу, оформив все примерно так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
table CLIENT
(
ID,
ADRESS_ID,
...
);
table ADRESS
(
ID,
CREATED_DATE, // все адреса клиента можно отсортировать в хронологическом порядке
UNIT_NO,
HOUSE_NO,
STREET_ID,
...
);
table STREET
(
ID,
STREET_TYPE_ID, // улица, бульвар, переулок, шоссе, ...
CITY_ID,
...
);
table CITY
(
ID,
CITY_TYPE_ID, // хутор, деревня, село, пгт, город
STATE_ID,
...
);
table STATE
(
ID,
PARENT_ID, // ID родительского STATE
STATE_TYPE, // район, волость, область, автономный округ, федеральная земля, кантон, ...
COUNTRY_ID,
...
);
Сущность STATE имеет древовидную структуру, т.к. в разных странах уровень вложенности единиц адм.-терр. деления разный (Владимирецкий район относится к Ровенской области в Украине, кантон Берн не не имеет родителя в Швейцарии. А город Нетешин в Хмельницкой области в Украине является городом областного подчинения, т.е. для него STATE_ID = "ID Хмельницкой области", а не Славутского района, в котором он расположен территориально.
Конечно, если БД нужна только для обеспечения обратной связи с актуальными на данный момент клиентами, то Вашей структуры БД хватит. Но перспектив в плане развития у нее явно никаких нет. Хотя, конечно, если встанет задача запоминать более чем один предпоследний адрес, то можно добавить еще N полей...
