|
zvezda_t
JohnSparrow , я поняла логику организации ваших таблиц :) , благодарю!!!
Всегда пожалуйста, уважаемая zvezda_t , :)
Cane Cat FisherJohnSparrow,
А к первой схеме сразу вопрос: хорошо, мы определили, что "Москва, д.1" не пропускать - необходима улица. Но ведь для деревни Собакино, дом 1 без улицы допустим! Значит, таблица ограничений должна привязываться не просто к типам объектов, а к их конкретным экземплярам - для Москвы одно, для Собакино другое. Может быть, настроить в таблице ограничений предопределенные шаблоны допустимости адресов - допустимую иерархию классов, а для каждого населенного пункта указывать ссылку на шаблон.
Cane Cat Fisher , во-первых, спасибо за ссылку на подобную тему. Прочитал. Как я понял, там Вы подняли тот же вопрос: "г.Москва, кв.10" - как избежать; и Вам ответили, что оператор может ввести это, а избегать следует организационными методами. Надеюсь, я понял правильно и, если так, сам присоединяюсь к мнению Ваших собеседников.
Далее небольшое рассуждение на тему (все - ИМХО, естественно). В общем случае база данных должна максимально полно отражать реалии предметной области (например, не заводить виртуальных улиц, если реально их нет). Но для отражения этих реалий сама предметная область должна быть неплохо структурирована, каждый тип сущностей должен иметь набор признаков, однозначно отделяющих его от другого типа. Например (обсудим населенные пункты, оставив пока в покое области, округа и т.п.):
тип "Город" - сущность, которая состоит из улиц и/или микрорайонов
тип "Село" - сущность, которая состоит из улиц и/или домов
тип "Деревня" - сущность, которая состоит из домов
и в реальном мире всем существующим населенным пунктам нужно сменить тип. Например, село Иваново из двух домов станет деревней. И т.д. К сожалению, реализация этого дела произойдет только после наступления Эры Роботов, :).
В случае с адресами проблема как раз в том, что реальные типы существующих населенных пунктов сложились исторически и далеко не всегда употребляются одинаково (в одном городе есть отдельные дома - сами по себе, в другом каждый дом обязательно относится к определенной улице). Т.е. предметная область состоит из сущностей, отличительные признаки которых не формализованы или формализованы слабо. Поэтому, действительно, требуется сохранять списки допустимых иерархий для каждого конкретного города/села/деревни/района и т.д. Видимо, это будет наиболее точное отражение предметной области. Ясное дело, поддержание такого классификатора в актуальном состоянии - задача сложная и мутная.
Другой вариант. Мы создаем таблицу типов (ADRESS_TYPE) и таблицу связей (ADRESS_TYPE_RELATION) - какие типы могут быть дочерними для данного типа. А типы у нас такие (применительно к нас. пунктам):
город
город, в котором может быть не указана улица
село
село, в котором может быть не указана улица
...
Дополнительно создаем таблицу ADRESS_NAME - общеупотребительные названия типов населенных пунктов (город, село, деревня, хутор, поселок и т.д.). Теперь для каждого блока адреса мы будем хранить [ID названия] и [ID типа]. Например (название, имя, тип):
город Москва (город)
город Верхнефуцынск (город, в котором может быть не указана улица)
деревня Кнуровка (село, в котором может быть не указана улица)
деревня Дунаевка (село)
При отображении оператору/пользователю используется связка ADRESS_NAME - ADRESS_BLOCK: "город Москва". Но при регистрации адреса система проверяет тип адреса. Т.е. адрес "Москва, дом 10" она отвергнет, а "Верхнефуцынск, дом 12" примет.
Таким образом, мы сформировали предметную область с четкими сущностями, а сущности реальной предметной области трансформировали в названия ("город" в "город Москва" при выводе на экран), которые вообще ни на что не влияют. Остается проблема - и здесь для каждого нового адреса требуется выяснить его тип - т.е., по сути, собрать досье на отдельные населенные пункты, районы и другие адм.-терр. образования. Вариант решения может быть следующий:
мы ассоциируем типы адресов между собой (например, записи ADREE_TYPE "город с улицами" и "город без улиц" относятся к ADRESS_NAME "город")
для каждого ADRESS_NAME мы храним ссылку на наиболее строгий из его ADRESS_TYPE (для "города" тип "с улицами" строже, чем тип "без улиц")
при регистрации нового адреса система оценивает его допустимость для данного типа и, если он недопустим, начинаются организационные процедуры. Если по итогам расследования оказалось, что в городе Москва (тип "город") есть адрес "Москва. дом.12", то мы изменяем тип Москвы на "город с улицами и отдельными домами" и успешно регистрируем "некорректный" адрес.
Вывод: получится тот же классификатор, но к "Москве" привязывается не отдельный набор допустимых иерархий, а ссылка на шаблон ("тип" в терминах предыдущих абзацев).
Cane Cat Fisher
Ну и осмелюсь повторить свой первый вопрос - "Вывести всех клиентов, живущих в заданном объекте иерархии" (поскольку с улиц-домов Вы спрыгнули :), например, в Приморском крае, если клиенты привязаны к подчиненным узлам иерархии произвольной вложенности. Только чур, оставим на время оракловский CONNECT BY - хотим, чтобы работало на любой СУБД.
Судя по всему, для забивания гвоздей все же стоит использовать молоток, а не абстрактный инструмент из дерева и металла. Если в базе предполагаются иерархические хранилища (таблицы, группы таблиц), то имеет смысл выбирать СУБД, которая поддерживает иерархические запросы. Я писал про Firebird, ее SQL реализует конструкцию WITH RECURSIVE n(...) AS (...) SELECT...
Ну а если рассматривать абстрактные сферические СУБД в вакууме, то давайте остановимся хотя бы на реляционных (я с другими вообще не знаком, так что остановка обязательная, :( ). Раз сервер не умеет, такой запрос может сделать клиент. Допустим, соответствующий метод клиентского класса принимает ID родительского элемента (некоторого района Ростовской области) ID_родителя, а далее он
запросом получает список всех ID, где PARENT_ID = ID_родителя
преобразует список в строку вида "12, 324, 415, 657, 1089" - это strChildAdresses
получает всех детей, чьи родители перечислены в strChildAdresses - "SELECT ID FROM ADRESS_BLOCK WHERE PARENT_ID IN (" + strChildAdresses + ")"
сохраняет результат в новую строку и т.д.
В итоге получим массив строк, в каждой из которых список DI через запятую. Нулевой элемент массива - список детей исходного ID_родителя, первый - список детей, чьи родители перечислены в нулевом и т.д. Потом мы пишем высокотехнологичный запрос вида "SELECT * FROM CLIENTS WHERE ADRESS_ID IN (ХХХ)", где "ХХХ" - конкатенация всех строк с перечнями дочерних ID из массива. Оно, конечно, получится несколько запросов к базе со стороны клиента, но ведь почему-то выбрана неподходящая для данной задачи СУБД, так что...
Второй вариант: на стороне клиента иметь глобальный объект - "дерево адресов", загружать его при инициализации клиентского приложения и реализовать тем или иным способом политику его синхронизации с БД. Очевидно, здесь много возни и простора для косяков.
|
