2 All
Не надо забывать, что тут не все еще "состоявшиеся разработчики" (относительность термина опустим) и "у меня в голове опилки" (с). Не надо уклоняться от темы, хотя я понимаю причины такого уклонения. Во блин, чайник пытается выступить в роли модератора!

2 iscrafm
Я подразумевал, что раньше как раз и подстраивал под интерфейс структуру таблиц. Потом понял (с подачи softwarer), что это неправильно. Приведу пример. Данные таковы, что являются иерархическими с довольно большим числом уровней, порядка 30. Но для практической работы на определенной форме мне нужно отразить только два. Значит, по-вашему, я должен был сделать 30 связанных таблиц для каждого уровня? Сделал две таблицы – собственно объекты и уровни иерархии. Есть еще какие-н. варианты в этом случае кроме 30 таблиц или двух? Пользователь – только я.

> Интерфейс и структура данных - неразрывны.
В том плане, что работают вместе. А разрабатываются отдельно. Т.е. как выглядит интерфейс не должно зависеть от структуры данных и наоборот. Надо мне будет дерево (см. предыдущий пример) – сделаю дерево, нужны будут комбобоксы – сделаю комбобоксы. Все равно таблиц 2 будет. Ну а код, естественно, будет разный при разных способах реализации, а по-другому и не бывает. Ну что я тут за softwarer'а Вам все повторяю? В конце концов, мне это как-то и по статусу не положено.

> Идет борьба интерфейсов.
Я правильно понимаю, что кому-то нравится один интерфейс, а кому-то другой? И теперь архитектор БД должен сидеть и ждать, пока они договорятся, сколько ж ему таблиц рисовать – 30 или 2? А если они потом поменяют решение?

> Продолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных СТРУКТУРАХ данных
softwarer: "Безусловно. Потребность в определенном интерфейсе определяет потребность исключительно в определенном СОСТАВЕ данных".
Правильно. Позволю себе уточнить? Имхо. Потребность в определенной информации определяет состав данных. Потребность в определенном способе визуализации информации определяет интерфейс. Так выражается опосредованная зависимость между составом (но не структурой!) данных и интерфейсом. И тут как бы все ясно и понятно. Какая тебе нужна информация, такой состав данных загоняешь в БД. В какой форме нужно выводить информацию, такой интерфейс и проектируешь. А мы здесь пытаемся выяснить структуру данных. И потребность в определенном интерфейсе не определяет потребности в определенной структуре данных.


2 Сахават Юсифов
Давайте только не будем поднимать и тут тему EAV. Если уж так хочется – плиз в топик "база товаров …", там это будет ближе к теме.
И вообще, давайте примем, что БД – это система. Теория систем гласит, что ни одна из них не может быть оптимизирована более чем по одному параметру. Тогда все дискуссии отпадут. Хочешь, чтоб была гибкая система – делай EAV. Есть устоявшаяся структура данных и желаешь обойтись меньшим количеством кода – делай стандартно. Все дальнейшее обсуждение в рамках топика я, пожалуй, не буду комментировать, ибо много и уже было.

2 mcureenab
> ИМХО, тебе надо получше познакомиться с инструментом, который собираешься использовать, тогда и вопросы многие отпадут.
Абсолютно согласен. Но, предположим, что я не буду работать с картами. Тем не менее, в базе должны быть возможности по работе с произвольными полигональными объектами. Ведь ссылки-то авторов на них есть. Как мне быть? Получается, что реализовать задачу можно ТОЛЬКО с помощью картографической подсистемы?

> Сегодня на канале ВЕСТИ рассказывали как американские чуваки в супермаркеты ходят. Если чувак не нашёл нужный ему товар, то он лучше не купит ничего, чем будет искать аналог...
Не все аналоги всем доступны, но если другого выхода не будет – придется переходить. И, кстати, если мне нужен кизлярский коньяк, то вряд ли я куплю французский в отсутствие кизлярского, хотя, в общем-то, аналоги, ибо дорого.

> Ну нету типа с именем BLOB, есть другие достаточно ёмкие типы. Наконец двоичные данные можно просто во внешних файлах хранить даже не привязывая их к БД.
Совсем не привязывать? Даже пути к ним не прописывать? А как же ссылаться?

> Придумай алгоритм…
Ага, все правильно. Но (см. выше), если не будет картографической подсистемы?

2 softwarer
> И совершенно не причина приписывать хрен знает какую глупость коллеге КД.
Спасибо, softwarer!