Как организовать хранение данных в БД?

Question

[Kniaz_kem]

Есть задача организовать хранение адресной базы начиная с города и заканчивая лицевым счетом абонента.
имеет следующий вид:
город
--улица
---номер дома
-----квартира
-------лицевой счет абонента.
Количество записей примерно 1 млн, увеличение записей в год - небольшое, примерно - 10-20 тыс.
На самом деле уровней больше чем я представил на дереве (например области, районы и т.п.)
Один деятель предлагает все это организовать в одной таблице в виде иерархии, оперируя тем, что дескать лучше хранить в одной таблице и удобнее с ней работать как в интерфейсе так и в БД (используя connect by), чем с несколькими таблицами обычным способом (используя join).
В интерфейсе и отчетах постоянно нужно как полностью развернутые данные по полям, а именно, город, название улицы, номер дома, квартира, лицевой, так и такие сочетания как город, лицевой и т.п. в любых комбинациях.
Какие есть проблемы при хранении данных в иерархической таблице(при удалении, редактировании, вставке, больших выборках по всем узлам, разбиение выборки по полям), по сравнению с обычными join'ами из нескольких таблиц?
(используемая СУБД- ORACLE 11g, среда программирования - DELPHI 7).

Answer 1

[Денис]

Города:
id, name

Улицы
id, id_города, name

Абоненты
id, ФИО, id_города, id_улицы, дом, квартира, телефон, мыло, возраст, пол, потолок

Счета
id, id_абонента, баланс

Запрос "Вытащить всех абонентов с балансом 3 рубля"
SELECT * счета WHERE баланс==3 LEFT JOIN абоненты ON абонент.id=баланc.id_абонента ну и джоиним остальные таблицы при необходимости

Вытащить всех абонентов из города ГГГ
SELECT * FROM абоненты WHERE id_города==ГГГ

Answer 2

[Geny]

Как мне кажется таблица вида (id; value; parent_id) не подходит, не хватает еще одного поля "тип записи" (город/дом/ и т.д.) т.к. иерархия разноуровневая получается.... (например часный сектор и квартиры нет).
Я бы соорудил 4-ре справочника город, улица, номер дома, квартира + табица вида (id, id города, id улица, id номер дома, id квартира, лицевой счет абонента) и все это в индексный кластер...
как то так

Comments

[Kniaz_kem]

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

Answer 3

[Александр Борисович]

А где у вас иерархия то?) Может чего не понял.
5 столбцов. обычная реляционная таблица.

Лицевой счет абонента
| id | value |
| 5999 | 8787878787|

город
| id | value |
| 5999 | Москва |
| 5998 | Питер |

и тому подобное. при выводе просто выводите все с таблиц с нужным ID.

Answer 4

[Kniaz_kem]

Да вот собственно иерархия:
город
--улица
---номер дома
-----квартира
-------лицевой счет абонента.
В вашем ответе вы наверно имели ввиду что надо создать 5 таблиц:
Город (id,value);
улица(id;value;FK_город);
номер дома (id;value;fk_улица);
квартира (id;value;fk_номер_дома);
лицевой счет (id;value;fk_квартира).

Собственно у нас идет борьба либо сделать так, либо сделать одну иерархическую таблицу вида -картотека (id; value; parent_id).

Так вот вопрос, у кого большой опыт работы с иерархическими таблицами, что удобнее в данном случае? какие могут быть проблемы?

Answer 5

[xtender]

Может лучше отталкиваться от КЛАДРа какого-нибудь?