Доброго времени суток всем!

Есть задача, непростая ...

Есть некая таблица Documents, являющаяся основной таблицей хранения документов. В ней есть фиксированное количество полей, являющиеся стандартными атрибутами документов, пока их 20.
В зависимости от типа документа могут потребоваться дополнительные поля для хранения дополнительных атрибутов, кроме этих 20-ти стандартных. Т.е. так называемые user defined fields.
Вопрос - где и как их лучше хранить?

Вариант 1, нерациональный из-за появления дырок, например, вот поля из Documents:
Id, Date, Category, Name, Qty, ... ,Status, UserDefinedField1,UserDefinedField2, ... , UserDefinedField10
Дырки получаются тогда, когда для документа одной категории не задействовано ни одного дополнительного поля, а для документа остальных категорий задействовано одно или два и только для какого-то одного задействованы все 10 доп.полей.

Вариант 2. Вроде бы рациональный, но заставляет плодить новые таблицы на каждый тип документа.
Вот будут поля из Documents:
Id, Date, Category, Name, Qty, ... ,Status
Далее, при необходимости ведения дополнительных атрибутов я на каждый новый тип документа создаю по новой таблице с четко определенным и только нужным количеством полей, например, MyDefinedTable_1 имеющая всего два дополнительные поля и поле id для связки с основной таблицей - Id, AddField1, AddField2. Далее, MyDefinedTable_2 имеющая всего пять дополнительных полей и поле id для связки с основной таблицей - Id, AddField1, AddField2, AddField3, AddField4, AddField5. И так далее, по одной таблице на каждую категорию, где не хватает стандартных полей.

Есть ли вариант 3?

Что рациональнее?
1) С точки зрения структуры БД
2) С точки зрения постоянного прироста кол-ва документов, скажем по 1000 в день
3) С точки зрения дальнейших поисков по контексту по всем документам и их дополнительным полям?

4) Не умрет ли такая структура при наличии скажем, миллиона записей и не подвиснет ли СУБД при поиске по всем атрибутам по контексту, например когда у меня будет 20 разных категорий документов, т.е. 20 дополнительных таблиц, в каждой из которых надо будет вести поиск по контексту в связке с основной.

Знатоки проектирования БД, откликнитесь плз, не хотелось бы спроектировать изначально кривую систему.

Заранее всем спасибо.

авторuser defined fields - все одного типа?
если да, то вариант 3 - сделать одну дополнительную таблицу с ID_документа, ID_дополнительного_атрибута, значение_дополнительного_атрибута.

- нет, данные разные, длин полей тоже. Наверное такой вариант не подходит.

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

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

Да, самое важное то я и забыл. Нет привязки на конкретную СУБД, желательно чтобы это работало максимально эффективно на разных современных СУБД.

2 BULK INSERT:
Если знаете ссылки или ключи, по которым поискать, подскажите пожалуйста. Все мои попытки поиска не дали ожидаемого результата, потому и написал здесь.

2 Bely:
Спасибо, линк почитаю.

На счет серверной части планирую все упростить - не делать ХП, вью, триггары итп. Только для хранения данных, т.е. нужна просто расширяемая структура таблицы.