Народ, скажите что думаете!!!

Есть таблица, допустим "ОБЪЯВЛЕНИЯ", одно объявление может принадлежать разным городам и странам. Т.е. связь с "LOCATIONS" МНОГОЕ КО МНОГИМ. Объявление может принадлежать как Стране, так и Области или Городу и тп.
Огранизация дерева "LOCATIONS" использовал принцип DBTree.

А теперь, для того чтоб выбрать все объявления к примеру России, нужно выбрать всех детей, а затем либо сабселектом либо джойном выбрать объявления (+ всякие фильтры + сортировка).
В программе %50 всех запросов будет такого рода.
Получается при выборке всегда нужно использовать 3 таблицы.

А вот собственно вопрос.
Может использовать схему:

ID_LOCATION имеет номер до 1 000 000 000 000 (INTEGER)
000 -- районы города
000 000 -- города
000 000 000 -- области
000 000 000 000 -- страны

Например Россия имеет код 1 000 000 000.
Таким образом мы исключаем выборку детей, т.к. знаем что дети России это число между 1 000 000 000 и 2 000 000 000.

Если Москва имеет 1 000 001 000 то дети будут числом между 1 000 002 000.

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

Кто что скажет?

egorychможет диапазона для детей-то и не хватить... одно дело - Москва, другое дело - Урюпинск

Вы хотите сказать что Урюпинск может иметь больше единиц детей чем Москва?

Получается что на каждую сущность для детей отводится по 1000 ячеек.

egorychвообще я хотел сказать обратное (про москву и урюпинск если), но суть вы уловили правильно. что случится, если потребуется создать 1001-го ребёнка? ну и вы уверены, что в России всего 1000 городов... и т.д.


Согласен.

Что ещё можете сказать на счёт такого подхода?
Стоит ли так заморачиваться?

anydasaegorychвообще я хотел сказать обратное (про москву и урюпинск если), но суть вы уловили правильно. что случится, если потребуется создать 1001-го ребёнка? ну и вы уверены, что в России всего 1000 городов... и т.д.


Согласен.

Что ещё можете сказать на счёт такого подхода?
Стоит ли так заморачиваться?

Хотя не согласен, в Стране есть возможность хранить 1 000 000 городов или 1 000 областей у каждой из которых по 1 000 городов.

Вряд ли где то не хватит разряда

proposed amendmentanydasa[quot egorych]Что ещё можете сказать на счёт такого подхода?
Стоит ли так заморачиваться?

тынц

proposed amendment, спасибо за ссылку, не догадался что это называется "интервальное дерево".
как думаешь, в данной задаче этот метод подойдёт выгоден?

Senya_LКонкретный пример. Попробуйте составить запрос, выборки всех объявлений, сделанных в городах областного подчинения. ;)

Senya_L Проблема будет такая же, как и в КЛАДРЕ. Для краткости: оптимизатор не может использовать индексы для предикатов типа LIKE '%001%'. Увы. В КЛАДРЕ коды в виде строки, а Вы хотите использовать числа, но сути не меняет.


Почему, по моему это совсем разные вещи. Например

или

где get_right_key() функция которое просто вычисляет правый ключ.

Senya_L
Конкретный пример. Попробуйте составить запрос, выборки всех объявлений, сделанных в городах областного подчинения. ;)

:)
Интересно, а при какой структуре это будет легко?

Senya_LВ смысле?

Запал Ctrl на буке, и нажал Enter, что и привело к отправке сообщения, сорри

Senya_LВычисляемое выражение и индекс не может быть использован. table scan со всеми вытекающими.

Простите за возможно глупый вопрос, а это правило для всех СУБД?

Senya_LНормальное древо + CTE
Использую PostgreSQL, там такого ещё нет.

Senya_L Используйте Firebird (из бесплатных), начиная с версии 2.1.

Я только на Postres перешёл :).
Да и потом в следующей версии обещают эту фичу прикрутить.

Вобщем, думаю пока буду использовать это .
Спасибо за отзыв.

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

Хорошая идея, Сергей! Нужно обдумать. Ложить по типам, кода в разные ячейки. И работать с таблицей легко будет, и код будет самоописывающим. Можно ещё ввести всякие правила, например:

Сталица страны имеет код вида *** *** 001 *** и тп.

proposed amendmentугу... начинается колхоз...

Грубо!

Сергей из Самары
И справочник можно по каждому типу построить. Страны с кодами, регионы с кодами и т.п.. Щелкаешь, выбираешь страну, регион, город и т.п.
Сергей из Самары

Если Вы имели ввиду реальные кода, то мне кажется это создаст больше проблем.
Захочется следить за этими кодами, а при изменении кода, нужно обновить код у всех детей и следовательно обновится ID у всех затронутых записях, что не очень хорошо.


А вот про столицу не понял. И главное зачем? Столицу можно и по-другому отмечать, а такая нумерация будет выбиваться из общей логики.

А зачем, только из-за городов вводить новое поле? Если можно описать так?
И почему это назвали колхозом я тоже не понял:)

Сергей из Самары
И справочник можно по каждому типу построить. Страны с кодами, регионы с кодами и т.п.. Щелкаешь, выбираешь страну, регион, город и т.п.

Если Вы имели ввиду реальные кода, то мне кажется это создаст больше проблем.
Захочется следить за этими кодами, а при изменении кода, нужно обновить код у всех детей и следовательно обновится ID у всех затронутых записях, что не очень хорошо.



Сергей из Самары
А вот про столицу не понял. И главное зачем? Столицу можно и по-другому отмечать, а такая нумерация будет выбиваться из общей логики.

А зачем, только из-за городов вводить новое поле? Если можно описать так?
И почему это назвали колхозом я тоже не понял:)[/quot]