daunitoВообщем суть вопроса. Есть готовый небольшой проект, который выводит несколько отчетов. Но у каждого клиента отчет немного отличается. Начальство хочет задумать какой-нибудь механизм, позволяющий на месте внедрять новые справочники и привязывать их к отчету. Причем формы должны подхватывать эти справочники и позволять вводить значения. Очень слабо представляю как это можно реализовать. Динамически добавлять таблицы или столбцы мне кажется утопией. Но и чтобы добавить колонку в отчете не очень хочется каждый раз перекомпилировать проект. Как можно поступить в этом случае?

А какая у вас отчетная система? Как она работает? Как выглядит?

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

LSVЭто стеб такой ?
В крупных корп. системах кол-во справочников (большинство - мелкие) может быть много сотен.
Лепить кучу одинаковых таблиц с двумя, тремя полями и кучей однотипной логики ?????? ЖЖОТЕ !
И что? Хоть тысяча справочников.
Во первых. Есть такое понятие ограничение целостности БД, как вы будете его обеспечивать, если у вас будет одна таблица на все справочники? Кодом? Триггерами? Лишняя работа и вероятность появления ошибки. Тоже самое касается безопасности, как вы будете ограничивать доступ до справочников.
Во вторых не справочники одинаковые, у кого то используются суррогатные ключи, у кого то фиксированные коды, не говоря уже о структуре справочника (количество и тип полей). Как вы это все запишите в одну таблицу? А есть же еще и древовидные справочники.
В третьих все почему то бояться лепить кучу форм для работы со справочником, мол на каждый справочник придется лепить форму. Решение простое. Создайте динамическую форму, которая читая метаданные сама строит котролы. А если решение на дельфи там вообще только запросы достаточно генерировать.
В четвертых вы подумали о производительности, о тюнинге БД, по вашей логике 100 справочников допустим в среднем по 20 значений в справочнике итого для того что бы найти нужное значение нужно перелопатить 2000 записей, хотя нужно было всего 20. У вас не будет возможности раскинуть справочники по разным табличным пространствам, что бы часто используемым выделялось бы больше ресурсов, например выделить побольше буффер пул. И еще куча нюансов.

LSVВсе проверки или в ХП или прямых запросах с клиента.
У вас наверное и все таблицы закрыты и обращение идет только через хранимые процедуры? :)
Знаем мы такое проходили. Ничего хорошего это не сулит. в большинстве своем куча лишнего кода, где в начале каждой хранимки идет проверка, а может ли пользователь что то делать.

LSV
Дело в том, что проверка целостности данных не ограничивается только запретом удаления при наличии ссылки. Делать же несколько принципиально разных механизмов сложно и глупо.
Например у нас проверка это некая ХП иногда с сотнями строк нетривиального кода.

Тут проблема в том что это проверка помогает от случайных ошибок. Проверка работает на самой таблице, что дает вам гарантию что кто то в обход вашей ХП не внесет не корректные данные.
Плюс дает информацию о структуре БД, сразу можно посмотреть куда ссылается то или иное поле.
Я не говорю что ваш подход не правильный, однако его тяжело соблюдать. Люди меняются, с документацией как всегда туго

LSV
Для сотен справочников из двух полей на 5-100записей делать отдельные таблицы ?
Ну делайте, если Вам не лень !

На самом деле это только кажется что плодить кучу справочников это сложно. Написать create table не так уж и сложно.

p.s. возможно мы по разному смотрим на БД, я на нее смотрю с точки зрения СУБД, а вы с точки зрения приложения.