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

Страна (если нужно) - Почтовый индекс (если нужно) - Регион - Район - Тип НП - НП - Тип дополнительного НП - Дополнительный НП - Тип улицы - Улица - Дом - Корпус - Строение - Квартира - Дополнительная информация. 

Добавлено через 46 секунд

Это к "Типу НП", видимо.

1. Опиши словами проблемную область.
2. Выдели сущестительные, прилагательные и глаголы.
3. В идеале существительные - это сущности, глаголы - связи, а прилагательные - атрибуты.
4. Составь ER-диаграмму.
5. Покажи, что получилось, полнее опиши задачу и тогда жди более исчерпывающего ответа   .

Gluttton, проблема такая.
Необходимо вносить в базу данных людей одного конкретного региона.
Регион это область. Есть город, есть поселки городского типа, есть сельская местность. Мне нужно организовать структуры БД таким образом, чтобы правильно отобрать критерии полей в которых будет вноситься информация. Тоесть у проживающего в городе отличный адрес проживания по структуре, чем у человека, проживающего в сельской местности. Правильно?

lumentek, прошу критику моего варианта.  


Неправильно. 

Добавлено через 1 минуту и 47 секунд

Ну-ка назови разницу между ними (с точки зрения разбиения адреса).   


А ещё есть в/ч, а/я, "до востребования".  

Вот это то и должен знать автор вопроса  ...

Прихожу я например оформить контрактное подключение к оператору мобильной связи, а там девушка пытается занести мой адрес в их БД. После десяти минут безуспешной манипуляции с сожалением возвращает мне паспорт и говорит, что мол ничего не выйдет, т.к. я прописан при воинской части, а адрес должен быть формата улица-дом-квартира  (случай из жизни).
А как Вам например такой шедевр: город Балаклава Инкерманского района города Севастополь (не шутка).

Собственно говоря это уже пища для размышления  ...

Я это всё к чему... Если я, как лицо, которое будет использовать (внедрять) разработанное ПО, зная всю бизнес-логику приложения предпологаю, что оно создано, только для конкретного района и будет использовано, только для лиц, прописанных в этом районе, то это одна история. А если, я собираюсь регистрировать в БД всех желающих (в том числе и иностранных граждан), то это совсем другая история...

По сути:
Ну я бы сделал как то так:
Таблица Районов (Код, Название, Центр, Прочее).
Таблица Населенных пунктов (Код, КодРайона, Название, ТипНаселенногоПункта, Прочее).
Таблица Улиц (Код, КодНаселенногоПункта, Название, ТипУлицы, Прочее).
Таблица Домов (Код, КодУлицы, Номер, Прочее).
Таблица Адресов (КодАдреса, Адрес, Прочее), где Адрес - это произвольная строка, которая может быть заполнена и как "строение 1, корпус 2, кв. 10", так и просто "кв. 25".

Но не зная для чего это используется, это всё пустые разговоры (и советы в том числе)...

Добавлено через 2 минуты и 19 секунд

Согласен.


Тоже согласен.

Хотя опять же таки:

Мне нужно вести учет клиентов пользования услугами одной компании. Это все для одного региона. Сам адрес этой косвенный показатель, он нужен только для общих сведений.  например при идентификации субъекта этих данных. Тоесть сами понимаете Ивановых И.И. может быть несколько. 
Теперь, по-вашему, предложению...

Таблиц а районов я так понимаю это, например, Воронежская область, г. Рамонск., с. Подольное.  
Так вот районом будет считаться Рамонский, а населенным пунктом Подольное. Правильно?

lumentek, может лучше взять оригинал и в нем посмотреть как реализовано?
Есть же общероссийский классификатор.

Подход наполненный потенциальными трудностями... При наличии составного первичного ключа (Ф.И.О., Адрес) возможны неточности, связанные с различными стилями написания адреса (например: Иванов И.И., кв. 7 - это один пользователь, а Иванов И.И. квартира 7 - это другой, а Иванов И.И., кв-ра 7 - это третий, хотя речь идет об одном и том же пользователе).
А как быть с Ивановым Александром Александровичем (отцом) и Ивановым Александром Александрвичем (сыном) естественно прописанных по одному и тому же адресу?

А чем не устравивает сурогатный первичный ключ?!

Т.е. в самом общем виде подход (на мой взгляд) должен быть таким:
- если в процессе эксплуатации БД не предвидиться действий с идентефикацией записей по адресу (выбрать всех тех, кто живет в городе таком-то или присвоить всем, кто живет на улице такой-то какой-нибудь атрибут), то адрес может быть и одним полем;
- если предется активное использование части адреса (выбрать всех тех, кто живет в населенном пункте таком-то), то эту (используемую) часть адреса необходимо вынести в отдельное поле;
- если есть необходимость различать записи по полному адресу, то все его сотавляющие необходимо вынести в отдельно в каждое поле (но тут возникает ньюанс, если предусмотреть такие поля как "корпус" или "строение", то для одних пользователей они будут заполены, а для других будут NULL, то же самое будет и с номером квартиры для жителей частных домов, хотя на мов взгляд ничего в этом смертельного нету).

А ещё есть такая штука как EAV (можно задать в поиске для этой ветке форума).

Это сообщение отредактировал(а) Gluttton - 19.11.2009, 09:04

А где его взять?

Добавлено через 4 минуты и 42 секунды
Gluttton, так я и хочу чтобы каждая часть адреса была в отдельном поле. Тоесть у квартиры поле Апартаменты, у корпуса - Корпус, у улицы - Улица. Тоесть для каждго типа отдельное поля. Это неправильный подход. Вся проблема в том что какие поля нужно учесть

lumentek, в гугле или яндексе вбивай "кладр 2009"   

Посёлок Рамонье, а не г. Рамонск.  


Вот теперь правильно. Кстати, "дополнительный НП" - это адреса вроде "Москва, Зеленоград" или "Санкт-Петербург, ПГТ Понтонный".  


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

неужто ты предлагаешь реализовать все в одной таблице?
Про дома и т.д., я предлагал посмотреть как реализовано, а доделать или создать все заново это выбор ТС

Данкинг, а если человек проживает в поселке в городе, то поля населенный пункт остаются пустыми?

Добавлено через 6 минут и 34 секунды


Мне это предложение интересно. Хочу уточнить некоторые детали.

1. Таблица районов? На примере допустим Белгородской области. Районы будут считаться Вейделевский, Валуйский, Прохоровский и.т.д.? Так?

Конечно, в одной, а почему нет? В данном случае с одной таблицей работать куда удобнее, чем с несколькими. Несколько таблиц для хранения адресной информации физических лиц я вообще не рассматриваю.  


Как понять "в посёлке в городе"?  "Населённый пункт" пустым быть не может. Меняется значение поля "тип НП": или "г", или "п", или что там ещё может быть.


Так.  Белгородская область, Прохоровский район, д. Ивановка, ул. Ленина, д. 10, корп. 11, кв. 12.

Это сообщение отредактировал(а) Данкинг - 19.11.2009, 15:59

Я имею ввиду такой вариант, если гражданин проживает в населенном пункте ПГТ, но тоесть если это прохоровский район, то он живет не в деревне, а в самой Прохоровке.  Или даже в самом Белгороде, который является центром Белгородской области.
В общем я понял вот  что.  Когда оператор будет вводить адрес, то программа должна сформировать строку адреса только по тем полям, которые будут ведены с учетом логики. Так?

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

Ничего не понял.  


Не сформировать строку, а внести адресные данные в соответствующие поля таблицы.


Что разделять, если адрес в таблице хранится в разбитом виде?

может и удобнее, но не более.
Для чего тогда нужна нормализация? Можно вообще все в одну таблицу, все наглядно и красиво, только есть куча проблем с производительностью, уникальностью, увеличением размера БД и т.д.

Deniz, есть человек, у него есть адрес. Зачем этот адрес разбивать по нескольким таблицам? Как тут выиграет производительность, уникальность и т.п.? Что хорошего, если фамилия в первой таблице, а номер квартиры - в десятой?

Это сообщение отредактировал(а) Данкинг - 20.11.2009, 10:42

Нормализация нужна для обеспечения согласованности данных.
Куда проще обеспечивать согласованность данных, если один объект(сущность) представлен в системе лишь единожды.
Однако избыточное увлечение нормализацией тоже пагубно. 
Если увлечься нормализаей,  все строки можно было бы представить как отношение лексем(слов), а все лексемы как отношение синтакссических единиц(букв). Тут даже нубу понятно, что наличие целесообразности в том является скорее исключением нежели правилом.

Я думаю следует придерживаться принципа бритвы Окамма - не стоит плодить сущего сверх надобного. Если вы проектируете, например, кадастровую систему и составные части адреса являются объектами этой системы, выделение сущностей город, страна, улица и т.п. вполне может оказаться целесообразным. Однако в большинстве систем адрес - просто некий информативный атрибут, который вполне даже может оказаться не заполненным или же он должен печататься только на конвертах. В этом случае нормализация избыточна. Если нужна достоверность адреса, проверки по КЛАДР при вводе вполне может оказаться достаточно. КЛАДР не так часто модифицируется, чтобы на это можно было нарваться.


Это сообщение отредактировал(а) Zloxa - 20.11.2009, 12:13

так вроде никто обратного не говорил.
полностью согласен, до тех пор, пока строка хранится в одном поле, как только ее разбивают на несколько слов, и каждое слово хранят в своем поле.
Если бы ТС сказал, что адрес будет хранится в одном поле, тогда можно даже отдельную таблицу не делать, вместе с описанием человека хранить, ноесли уж он решил разбить адрес на составляющие (поля таблицы), то есть смысл продолжить нормализацию.
Зачем это все нужно ТС я так и не понял, если идентификацией субъекта по адресу будет проходить визуально без поиска по адресу, то вообще весь адрес затолкнуть в одно поле и не мучатся.

Если адрес разбит, то при необходимости будет проще выделить некорректные адреса, к примеру, города без улиц или домов.

Данкинг, мы так опять вернемся к вопросу до какого уровня нормализовать.
Я высказал свое мнение.
Подождем ТС, может он прольет свет на задачу, вдруг это лаба   а мы тут выпендриваемся

Похоже, что в данном случае и нормализация не нужна. Можно обойтись древовидной структурой, сформировать которую можно из того же КЛАДРа. Написать конвертер для конкретной области, что бы проще было обновлять.