tasyushaВопрос в том, как спроектировать таблицу(ы) для хранения адресов

Ладно, открою тайну.

Беда в том, что понятие адресов - штука очень исторически сложившаяся, архаичная, полная исключений, и потому очень плохо ложащаяся в понятия реляционных баз данных. Если разозлиться, и попробовать охватить все варианты - получится что-то вроде упоминавшихся уже КЛАДР и ФИАС, но нужны ли они вам - решайте сами.

Начинающие разработчики часто пытаются сделать простое дерево вроде Область - Район - Населенный пункт - Улица - Дом - Квартира.

Типовые проблемы, с которыми они сталкиваются - города федерального подчинения, села без улиц, несколько одинаковых улиц в одном городе, понятие микрорайонов, кварталов, корпусов, строений, флигелей, военных городков, зданий без присвоенного адреса, и тому подобное.

Но все же на практике часто используют упрощенные модели. В пределе, например, работающее решение: Вы делаете сайт, рассылающий по почте бумажные рекламные каталоги. Пользователь заходит, регистрируется, и запрашивает себе каталог, для чего вводит свой адрес.

Так вот, адрес в США печатается конверте четырьмя строками. Решение в том, что для данного сайта совершенно достаточно хранить адрес всего лишь в виде четырех строковых полей, LINE_1 ... LINE_4, и выводить их на печать конверта в том виде, как ввел пользователь.

Если пользователь слегка ошибся в написании адреса - почтальон посмотрит, поймет. Если ошибся сильно - не получит каталог, сам себе дятел, невелика беда. Спрашивается, нужен ли тут КЛАДР или ФИАС?

Так и в информационных системах среднего пошиба вполне допустимо сделать самопальное упрощенное дерево, а возникающие единичные проблемы решать творчески, например в единственном селе без улицы сделать улицу с названием "без улицы". Ну вот, сейчас опять прибежит softwarer меня бить за такие идеи. Может, он что путное вам посоветует.

L_argoА зачем вообще группировать контрагентов по адресу ?
Например, чтобы составить оптимальный список для обхода, для бригады по выбиванию долгов.

L_argoЕсли уж так нужно привести все к единому знаменателю, то разношерстная инфа адресов просто заносится в таблицу соответствий и там проставляются ID-шки из единого эталонного справочника.
Если эталонный справочник существует, почему бы не дать пользователям просто выбирать из него?

Dimitry SibiryakovCane Cat FisherЕсли эталонный справочник существует, почему бы не дать пользователям просто выбирать из него?

Выбор из справочника обычно медленнее прямого ввода.

Не нужно смешивать вопросы организации интерфейса со структурой БД. Если в справочнике улиц тысячи строк, никто не заставляет пихать их в комбобокс или окно. Вполне можно сначала дать пользователю ввести три буквы, а затем дать выбирать из уже отфильтрованного.

Zmeelov2Mr.FontaineВесь адрес вручную, пользователь лучше знает по какому адресу он живёт не задумываясь над классификацией
Если адрес не значим - то да

Но один вопрос меня мучает. Если адрес не значим - зачем его вообще вводить?

А если значим - как можно допускать туда мусор?

Зная точный адрес, можно делать с контрагентом всякие интересные вещи, например подать на него в суд. А если у вас его адрес с опечатками да "сленговыми названиями" - нет, конечно, это не сразу так проигрыш в суде, но вполне возможны исправления и задержки в несколько месяцев, за которые он успешно сбагрит все свое имущество, и предстанет перед сами гол как сокол. Вот и подумаешь тогда, чего стоит точный адрес.