вопросик_vinger4я за вариант построчного хранения полей.
один из минусов - сложности в реализации даже такого простого ограничения, как длина строкового поля.Это не самое страшное - можно, в конце концов, триггер повесить.
А вот отчеты и поиск - это будет убийство.

вопросик_1) новые таблицы + таблица описания времени действия структуры
2) уже упомянутая структура (поля - построчно хранятся)
3) ...Я уже как-то писал чем можно заменить EAV при необходимости изменения структуры.
Есть еще следующие варианты, относящиеся к (3)

3а) Создать таблицу с фиксированным набором полей разных типов. "Строка" - 20 полей, "число" - 15 полей, "дата" - 10 полей.
Далее в метаданных надо будет указать какое физическое поле чему соответствует. Например "DATE1" = "Дата подписания договора".
При необходимости увеличения кол-ва полей - их можно просто добавить в таблицу.

Недостаток - сложность определения где какие данные лежат для разных версий документов.

3б) Поля никогда не удалять из таблицы, если они больше не используются (для истории).
Новые необходимые поля - добавлять в структуру таблицы. В метаданных хранить информацию какие поля в какой версии используются, а какие нет.

Недостаток - через некоторое время таблица может оказаться заполненой на треть/четверть или еще меньше.

3в) Использовать основную таблицу "Документ" в которой хранятся системные поля и общие для всех вариантов документа и несколько связанных с ней таблиц 1:1 с детальным описанием доп информации, которая есть в каждой версии.
Более подробно обсуждалось здесь

(3в) - видится наиболее сбалансированным.

вопросик_еще такой момент - для работы с меняющейся структурой данных использовать хранимые в бд запросы или динамически генерировать (~по какому-нибудь метаописанию) ?
(чтобы минимизировать изменения в клиентской части)Здесь я вижу два варианта:
1) Если настраивать систему будет обычный пользователь, то запросы генерить лучше динамически по метаописанию. Можно по созданному метаописанию - создать VIEW и его использовать в запросах вместо таблицы.

2) Если настраивать систему будет програмист, то непосредственно в метаданных можно хранить текст запроса, который будет использоваться.

3) Что использовать ХП или VIEW(SQL) - зависит от SQL сервера, архитектуры программы и много чего. Я бы порекомендовал использовать SQL запросы (или VIEW). В этом случа у сервера есть шанс оптимизировать запрос к БД при появлении доп условий.

вопросик_Насколько часто проверять изменение текста запроса (hash и тд) - перед каждым исполнением/ либо только при первом и какая-нибудь структура, отслеживающая изменения метаданных и работающих в данный момент в системе клиентов ?
Другими словами - варианты обновления версий системы.У вас сколько тысяч таких запросов будет выполняться в секунду?
Если как у обычных людей (зашли в форму, выполнили поиск, работаем дальше) - то проще зачитывать запрос при открытии формы.

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

MasterZivНет. Только EAV (а-ля Тенцер).Категорично, однако

вопросик_ Примерно такая ситуация: документ, структура его (то, что он включает в себя) раз в полгода-год немного меняется.
MasterZivНе, ну можно конечно один раз произвести изменение структуры,
сохранить в документах где-то версию схемы и потом
обрабатывать параллельно двумя способами всё в зависимости
от версии. Но это можно сделать один-два раза, а не 100.Расчитывать, что через 50-100 лет система будет такой же - ну, странновато, чтоли...