На мой вопрос внимания не обратили. Мои 5 копеек.
Описываю свою ситуацию. Поскольку справочники могут быть разными (разное число полей и разные типы), продукт будет стоять у большого кол-ва заказчиков (они сами делают справочники), то и в случае одной таблицы и в случае многих потребуется система управления справочниками. Сложность ее в обоих случаях примерно одинакова. Наличие команд DDL не является принципиальной сложностью при наличии определенных прав доступа. Документирование ведется для абстрактных справочников. Зато ссылочная целостность в случае разных таблиц не позволит получить чужой справочник там, где не надо. В моем случае все осложнается ссылкой из одного поля на элементы из разных справочников. Один из вариантов - категоризация. Подскажите еще варианты.

Petro123в вашем случае - клиент меняет структуру БД и создаёт таблицы в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.
200-300 таблиц - это плохо. Но какая сущность содержит 200-300 СПРАВОЧНЫХ атрибутов? Это либо очень спецефическая задача с автоматизированным вводом, либо ненормализованная сущность. Либо денормализованная намеренно таблица для достижения спецефических результатов. Какой менеджер будет использовать столько атрибутов товара, заказчика и проч.?
Насчет несоизмеримо - если справочники однотипные - да, а если нет? Управление полями в этой таблице выльется в крупную головную боль.
Гость1111Структура БД, состав документов, форм, и приложения должна быть определена на этапе проектирования.
Нет, поскольку система продажная, и состав заказчиков неизвестен до момента продаж, известен только класс решаемых задач. Например 1С не знают в момент проектирования, какие формы выпустит соотв. орган.
Petro123я бы сказал, если заказчик не просит-платит за "конструктор". Это как организовать продажу продукта. В любом случае реализация (1 или много таблиц) от заказчика будет скрыта и на интерфейсе не скажется. Критерий один - внутреннее удобство реализации и поддержки.

Petro123Например, учёт зданий-недвижимости градоначальника.
Сначала атрибуты - адрес, застройщик, площадь, ..........
После запуска в эксплуатацию потребовалось учитывать новый/ые атрибуты - ДавалЛиВзятку (BOOLEAN)
===========
Что будешь делать - проектировщик?
Внесу в метаинформацию запись об этом поле и запущу генератор.
В случае с одной таблицей - все равно вносить метаинформацию, генератор только не нужен. Акцентирую внимание на различиях - в одном случае нужен генератор, в другом невозможна типизированная ссылочная целостность через FK.

Внесу в метаинформацию
========== это в терминологии администратора БД и схемы БД где?
Не очень понял вопрос.

запись об этом поле и запущу генератор.
========== это что и приведи код (ХП\COM\ExtProc\DLL\.....)
Пока генераторы команд DDL были оформлены процедурами, будут наверное классами. Так удобнее. Сами команды легко структурируются.

В случае с одной таблицей - все равно вносить метаинформацию
=== какую?Сами написали:

Она во всех случаях одинакова.

, генератор только не нужен. Акцентирую внимание на различиях - в одном случае нужен генератор, в другом невозможна типизированная ссылочная целостность через FK.
========== вот это уже ближе к конкретики, ещё забыл, что DLL и генераторы это безопасность
Можно пояснить?

Alexey Kudinov У пользователя есть потенциальная возможность навернуть как минимум часть данных в таблицах (совсем не те, что "задумывались" разработчиками), а скорее всего и саму таблицу(ы).
Но и это еще не все. Главное(практическое) зло неконтролируемого изменения структуры БД - трудность последующего обновления и сопровождения такой системы.
С навернуть данные не соглашусь, команды выдает оттестированный генератор, максимальное зло при ошибке - отказ выполнить действие. Хтя потенциальная возможность действительно есть. Так - же как навернуть свои данные разом дав команду delete. В этом случае один из рубежей обороны отсутствует. Только я в своей практике еще с этим не встречался. А вот с сопровождением соглашусь. Все сопровождение придется делать через эти - же генераторы. Ихмо - целостность это перевешивает.