2 All
Я извиняюсь, что несколько торможу с ответами. Не успеваю за ходом дискуссии.


2 мод
> Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь.
Да, один и тот же функционал может быть реализован различными вариантами интерфейсов. При этом состав и структура данных одни и те же.


2 iscrafm и softwarer
Не ругайтесь. Давайте вернем дискуссию в конструктивное русло.


2 iscrafm
> Образно говоря, если Вам требуется представлять данные в виде деревьев, то Вы должны позаботиться о соответствующей структуре, хотя бы предусмотреть в таблице поле для связи с PARENT. Я говорю именно об этом.
А если не образно, а конкретно, поле PARENT я лично ввожу, чтобы показать иерархическую связь между объектами. А будет ли оно использовано для дерева, в запросе или еще как-то – дело десятое. Вот и Анатолий Иванов правильно проиллюстрировал эту мысль.

> нет, по-моему Вы не должны делать 30 связанных таблиц для каждого уровня.
Правильно, не должен. Вот я и пришел к выводу, что достаточно 2 таблиц, чтобы отразить структуру данных. Далее над интерфейсом можно извращаться как угодно. Сейчас поле PARENT в таблице объектов. Интересно, а если я его добавлю в таблицу уровней иерархии и/или уберу из таблицы объектов, как это повлияет на функционал?

> Состав данных никоим образом сюда не клеится. Задумайтесь сами, как содержимое таблицы может повлиять. Вы думаете разработчику интересно, что в его справочник занесут, "Маша" или "Петя"? Нет, не интересно. Единственное в данном контексте (состав данных) что интересно, так это типы и размеры данных. Но это уже вопрос структуры.
Нет, кажется, мы с Вами по-разному понимаем термин "структура". Тип и размер данных – это, по-моему, свойства данных, обусловленные их природой. Содержимое таблицы – состав. А вот как выглядят сами таблицы, какие таблицы с какими соотносятся и т.д. – это уже структура.


2 Сахават Юсифов
> Есть многокритериальная оптимизация.
Кто ж спорит, конечно, есть. Но каждый из критериев, поучаствовавших в такой оптимизации, будет оптимален, если можно так выразиться, не на 100%, а только в контексте остальных критериев. Путано объяснил, но, думаю, Вы меня поняли.


2 mcureenab
> В базе, работать ни с чем нельзя. Работать может СУБД или другая подсистема.
Ну да, да. Я имел ввиду под словами "база", что это данные и то, что ими управляет (СУБД).

> Ссылаться и привязывать, это несколько разные вещи.
Я имел ввиду – организовать ссылочную целостность. '

> Честно говоря я не вижу смысла работать с географическими объектами не имея возможности визуализировать их.
О, нет! Я ведь уже описал ситуацию, когда это могло бы произойти. Ну давайте представим, что нет еще ГИС'ов. Но есть BLOB'ы. В таком случае мы бы ведь могли работать "с географическими объектами не имея возможности визуализировать их"? Да, это был бы страшный гемор, но в принципе возможно. Хотя я к гемору не призываю. Я попробую связку Access+MapInfo, если не получится, наверное, буду переходить на SQL Server+MapInfo.