Bely softwarerЕсли Вас утешит, в Oracle использован другой подход - таблицы, представления, процедуры и все прочее описывается в различных системных таблицах. Как насчет ALL_OBJECTS ?
Как? Да очень просто....


Неужели это новость? Тут уж если спрашивать, можно было бы спросить про табличку SYS.OBJ$. Она действительно общая для всех объектов, но в ней лежат по сути только заголовки, общий минимум информации - типа id-name-status - а основная часть информации размещается в SYS.TAB$, SYS.VIEW$ и так далее.

EstetsГы гы гы, тогда можно сказать что в случее SUBJ мы храним в таблице simples_list : id, тип, наименование. А все остальное в DICT_STREET_TYPE... ;-)
Против такого подхода в случае subj я и не собираюсь возражать, сам иногда использую. Правда, в случае справочников не стал бы - геморроя больше, чем выгоды.

EstetsP.S. Шутка конечно, но на мой взгляд оба подхода равнозначны, обладая своими плюсами и минусами.
Не смешивайте понятия "равнозначны" и "обладая своими плюсами и минусами".

Также - не смешивайте "снежинку" из стержневой таблицы с расширениями с архитектурой "все в одном" - это разные вещи, опять же, обладающие своими плюсами и минусами.

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

Чтобы проиллюстрировать.... скажем, с давних времен известно два подхода к оптимизации - "по скорости выполнения" и "по потребляемой памяти". Дык вот, Ваша фраза аналогична фразе "нет никакого смысла менять один подход к оптимизации на другой".

Наконец, что касается именно архитектуры "все в одном" в случае именно таблиц-справочников в БД, "помогающие плюсы" практически отсутствуют (в топике не было названо ни одного), "мешающие минусы" я назвал.

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

В данном случае уместно посмотреть на такую категорию универсальных программ, как СУБД - тем паче, что только что обсуждали конструкцию системных таблиц. Вот уж кто легко мог бы реализовать такой вот "универсальный подход с появлением нового раздела в таблице", вместе со всеми EAV - ан нет, почему-то их "динамический sql" ну совершенно не пугает.

модУровни разные: СУБД и ее прикладнуха.
Именно что разные. Для СУБД такие вот "разнообразные таблицы" - основная функциональность, а не третьестепенная функция. Производители СУБД имеют возможность протестировать свое решение куда лучше, чем производители прикладного софта. Производители СУБД уверены, что даже если кто-то и полезет в эти таблицы грязными руками, техподдержка пошлет его в пешее эротическое. И все равно почему-то не делают. А авторы прикладух, видимо, храбрее :)

модТеоретически действительно можно все сделать на динамических sql,
Во-первых, не надо про "все", от "всего" в обсуждаемой теме справочников и одного процента не наберется.

модно на практике это довольно не просто,
Да бросьте.


модне говоря уж о производительности.
А что говорить о том, что не меняется?

мод softwarer Для СУБД такие вот "разнообразные таблицы" - основная функциональность
Как раз СУБД хранит все данные в своих внутренних фиксированных структурах.
В своих внутренних динамических структурах.

модА причем тут справочники, речь о подходе.
Справочники при том, что это основная заданная тема.

Что касается "подхода во всей широте", то говорить об универсальной программе, которая подхватит заданную структуру данных можно (хотя далеко не факт, что стоит), однако рассуждать при этом о трудностях динамического кодирования - напомню, это тот Ваш аргумент, который мы обсуждаем - просто смешно.

мод softwarerДа бросьте.
Для языков типа делфи динамический sql это нормально, но я не пишу на делфи
Вот и не надо выдвигать как общее правило - "будет непросто" - то, что верно для редкого частного случая используемого Вами инструмента. Более того, я твердо уверен в том, что технология должна влиять на выбор инструмента, а не наоборот - иначе говоря, если Вам нужны "динамические таблицы", надо выбрать инструмент, который может с ними нормально работать, а не корежить архитектуру под недостатки инструмента.

EstetsОдним из минусов "однотабличного" подхода для хранения однотипных справочников было названо сложность по расширению функционала в случае если одному из типов потребуются дополнительные поля.
Нет. Никакой сложности в этом нет. Есть уродство и возникающие проблемы.

EstetsСоответственно "снежинка" решает данный вопрос
Решает. Причем так, что возникает вопрос - а нафига теперь стержневая таблица :)

Estetsи не требует переделки SELECT-ов в случае если там используются только поля ID-наименование.
Расширение "одной таблицы" также не потребует изменения SELECT-ов, в которых используются только id-name. Не вижу, к чему этот аргумент.

Estets softwarerЭта мысль далее всего от истины. ......
Это было высказано на случай нахождения на данном форуме "горячих голов", которые бросятся тут же исправлять логику работающих программ. ИМХО не стоит этого делать, так как практически ни в одном случае плюсы любого из двух подходов не правышают затрат на переделку.
Давайте постараемся оборачивать обращение к горячим головам в более верные утверждения :) Что же по сути Вашего ИМХО, то не имею собственного мнения на этот счет - надо смотреть по месту.

EstetsГм, тогда исправим данное упушение. Плюсы универсального подхода:

1) Универсальность интерфейсной части, легкость внесения разработчиком и изменения пользователем значений и наименований "простых справочников", одно окно интерфейса.
Госсподи, опять. Ну кто, кто мешает Вам применить "одно окно интерфейса" для нескольких таблиц? В чем разница?

Этот аргумент выглядит примерно так же, как аргумент программиста, разработавшего три одинаковых фунции - "но ведь в одном случае результат нужно присваивать в переменную i, в другом - в переменную j, а в третьем - в переменную k". И затем победоносно избавляющегося от двух функций ценой присваивания всегда в одну переменную.

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

Estets3) Простота реализации Row-level доступов в справочникам, в случае если такой доступ необходим. Как с точки зрения настройки допусков к одной таблице, так и простоты реализации интерфейса настройки.
Ну и снова - в чем разница? Особенно в "простоте реализации интерфейса"? Разницу в реализации еще можно заметить - допустим, "несколько одинаковых вьюх вместо одной".

EstetsМинусы подхода 1 справочник - 1 таблица:

1) Разработка серверной и интерфейсной части под каждый новый справочник.
Госсподи. Ну если рисуете каждый раз заново, то начинать надо вовсе не с дизайна БД.

Estets2) Поддержка серверной и клиентской части. У нас зарегистрировано в системе 190 типов простых справочников. Это 1 таблица и 4 процедуры на Select, Ins, Upd, Del. В клиентской части это 1 пункт меню список с фильтром и вызываемый из списка редактор. Соответственно для подхода "1х1" это 190 таблиц и 760 процедур в серверной части и 190 кнопок/пунктов меню в клиентской.
Этот аргумент выглядит столь замечательно, что я цитирую его целиком. Тема замечательно соответствует недавно отгремевшей войне на тему многозвенного мышления и привычки многих не понимать разницы между структурой данных и отображением этих данных в интерфейсе.

Итак, Вы умеете отобразить "справочник категорий" в комбобоксе (или чем там), и, видимо, не умеете отобразить его же в виде ста девяноста пунктов меню. Вы умеете отобразить "справочник таблиц" в виде ста девяноста пунктов меню и не умеете отобразить его же в виде комбобокса (или чего там). И как результат, интерфейс ввода является аргументом при выборе структуры данных. Бесподобно. Я бы даже сказал, феноменально логично.

Попутно Вы признаетесь в привычке генерить по каждому случаю идиотские хранимки. И это тоже идет как аргумент при выборе структуры данных.

BelyЯ могу признаться, что для каждой таблицы я генерю "идиотские" триггера и сиквенсы, которые:
Во-первых, не путайте триггера с хранимками. Во-вторых...

Bely - Вставляют ID из последовательности
Отказался из соображений производительности. Лучше явно закодировать nextval в паре мест.

Bely - Выставляют автоматом дату создания и дату модификации записи
- Записывает USER_ID создателя и кто обновлял последний раз
Во-первых, откройте для себя default sysdate/user. Во-вторых, когда-то я работал с таким аудитом, но так и не понял прелести - поскольку нафиг теряется информация "кто предпоследний"... Тут уж если делать, то полностью.

Bely - запрещают изменять ID записи
Хм. А нафига? Хотя в принципе можно - если повесить триггер on update when (old.id <> new.id), тот не будет заметно тормозить.

BelyСущественно уникальные триггера - встречаются гораздо реже, чем вот такие типовые.
В последнее время в том, что делаю я, редко встречаются "существенно уникальные триггера" и вообще не встречается других.

BelyЛично я расцениваю трудозатраты на эту часть работы - как некоторое неудобство в случае с большим кол-вом таблиц, нежели как существенный аргумент.
Я не считаю этот аргумент существенным, но более потому, что сама по себе привычка генерить прорву кода есть "тревожный звоночек". А в том, что касается автогенерации CRUD (о которых говорил Estets), так и скорее о болезни головы.

EstetsСкипнуто несколько общих рассуждений ;)
То есть Вы с ними согласны?

EstetsРазница в построении и отладке интерфейса с 1 (одним) папаметризированным запросом. И интерфейса по обработке 190 запросов по условно одинаковым таблицам. Вероятност забыть чно на 130-ой таблице добавили триггерное ограничение а 140-ую кто то добавил мандатори поле без дефолтного значения.
Названные вероятности абсолютно равны вероятности того, что на единственную таблицу добавили триггер, срабатывающий только для 130-й и 140-й категорий соответственно. Разницы по-прежнему не видно.

EstetsНет ничего невозможного при неограниченном бюджете и людских ресурсах.
Вы это про поддержку 190 справочников в одной таблице? В общем, верно..

EstetsСм. выше, отладка занимает в 190 раз больше времени,
Заблуждение мягко переходит в состояние, характеризующееся более сильными терминами.

EstetsЧто такое интерфайс к Row-level допускам - матрица по вертикали значения из таблицы по горизонтали роли(пользователи) и галочки на пересечениях.
Именно так.

EstetsРазница в выборе значений из одной или N таблиц, часть из которых могут добавляться удаляться в процессе работы.
Так в чем разница-то? Давайте рассмотрим реализацию. В случае одной таблицы:

1. DBComboBox, заполняемый из справочника категорий.
2. Детальный к нему датасет с селектом, фильтруемым значением комбобокса (where category_name = :category_name)
3. Обработка кликов, выливающаяся в UpdateSQL.

В случае разных таблиц:

1. DBComboBox, заполняемый из справочника таблиц
2. Детальный к нему датасет с селектом (from &TableName)
3. Обработка кликов, выливающаяся в UpdateSQL.

Ни одной! строки разницы в реализации.

EstetsРазработка интерфейса для "автоматического рисования по примеру"
Еще раз: если не умеете делать - не говорите, что этого нельзя сделать. На любом нормальном инструменте можно написать одну форму, редактирующую указанную из множества однотипных таблиц. Без всякой дополнительной трудоемкости. Трудоемкость регистрации нового справочника - внесение одной строки в таблицу. Если используемый Вами инструмент так не умеет.... хм, я бы всерьез задумался, нафига он мне нужен.

EstetsЭто похоже на програмиста который хвалится написанным макросом для копирования функции возвращающей результат в переменную X в фунуцию возвращающую значение в переменную Y, пусть и в два клика а смысл?
Если это единственный способ, который Вы представляете для решения задачи "возвращать результат функции в указанную переменную...."

EstetsПри разработке приложений я обращаю внимание на два основных требования это:
1. Удобство для конечного пользователя
2. Скорость разработки приложения
Поскольку данные требования часто противоречат друг другу то приходится искать баланс.


EstetsИмея "справочник категорий" очень легко построить "комбобокс" или ДропДаунЛистБокс для выбора нужных категорий. С этим я надеюсь вы согласны?
Имея - легко. Я бы отметил, кстати, что по умолчанию мы его не имеем. Мы имеем только поле "категория" в общем справочнике, а отдельный справочник категорий - можем иметь, можем не иметь, as designed. Разница в том, что например "названия категории" во втором случае у нас не будет, неоткуда.

EstetsРаздел главного меню с 190-та позициями создать можно, но в связи с отсутствием поиска этот вариант отпадает так как противоречит пункту "Удобство".
Замечательно. Таким образом, когда Вы в предыдущем письме требовали при разных таблицах именно такого интерфейса, Вы пытались завязать вариант "разных таблиц" на заведомо плохое с Вашей же точки зрения интерфейсное решение, дабы оно утопило такую архитектуру - я правильно понимаю?

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

EstetsМожем создать одно окно и ДропДаунЛистБокс для выбора, но тогда мы столкнемся с необходимостью вести "мета-справочник справочников" где будет храниться информация по справочникам системы
Стоп-стоп-стоп. Значит, по-Вашему, справочник категорий мы "имеем без всяких усилий", а для справочника таблиц мы "столкнемся с необходимостью и натолкнемся"? Ну-ну.

EstetsИ опять мы наталкиваемся на необходимость синхронизации физических таблиц с метасправочником + динамические запросы на редактирование разных таблиц. Что противоречит пункту "Скорость разработки"
Второе - многократно опровергнутая чушь, которую Вы продолжаете повторять, причем так и не назвав ни одного аргумента. Такое впечатление, что Вы этого просто никогда не пробовали и боитесь по религиозным соображениям.

EstetsВообщем я никого не убеждаю, что данный подход лучше,
Да собственно убеждайте, только приводите аргументы, причем сколь возможно объективные. Напишите например - "вот для статического кода мне надо написать <мало кода>, а для динамического придется писать <много кода>, и этого никак не сократишь". Тогда мы увидим, сокращабельно или нет.

Впрочем, учитывая, что я уже не раз приводил код, и он ничуть не длиннее, уверен, Вы этого не сделаете.

Estetsно не стоит заявлять категорически "Я вижу только минусы и не вижу плюсов".
Тем более не стоит лгать. В последнем оживлении мелькнул единственный случай - Oracle Forms, где динамика доставляет проблемы (если я правильно понял). Я не готов считать это плюсом (поскольку, как объяснял, полагаю, что надо выбирать технологию под задачу, а инструмент под технологию, но не наоборот), но по крайней мере это реальность, которую мы можем пощупать и сказать - действительно, сложнее.

EstetsВ данном случае "генерить идиотские хранимки" было частью технического задания на разработку приложения и было установлено заказчиком,
Замечательно. Итак, это обвинение с Вас снято, но возникает вопрос: почему Вы преподнесли разовый идиотизм заказчика как глобальный недостаток технологии? Полагаете, это корректно?

BelyА если полностью - то он у вас не на триггерах будет?
Думаю, нет.

BelyПро пользователя - он у нас не ORACLE USER - он "пользователь системы".
:( Ну значит SYS_CONTEXT.

BelyСам же говорил, что это "личные проблемы"
Ну так и отвечает на такие же "личные проблемы", ситуация симметрична. Скажу так: когда-то у меня тоже было море триггеров, но чем больше я работаю, тем меньше их становится. Причем не потому, что они плохи как идея, а потому, что они слишком много тормозят и мешают - и становится лучше выбрать альтернативное решение без триггеров.