Dr_MikeВсе равно неудобно получается - еще какой-то дополнительный список будет висеть по нескольким реквизитам.

Думаю, придется заняться написанием чего-то по типу парсера - в поле будет храниться так сказать "гипертекст" с прямыми ссылками на документы.
Правда, чувствую, что поморочусь с отображением туда-обратно этого "гипертекста" :-((
Если действительно аттрибуты самих документов не так важны в базе данных, то можно посмотреть в сторону XML. Правда тут уже все будет зависеть от конкретной реализации СУБД, но например на Sybase ASA в "оправданных" случаях я делаю так:
1. Храню дополнительные и не особо нужные аттрибуты в поле с типом XML.
2. Записываю в них данные через специальные возможности ASA, позволяющие модифицировать данные в XML или же генеря XML через SELECT, у которого достаточно много заточенных под это опций.
3. Работаю с этими аттрибутами, используя LATERAL соединение (внутреннее соединение JOIN) и функцию OPENXML. Например если у меня в XML поле на каждую запись храниться такая структура:
то запрос получения этих аттрибутов будет такой:
На выходе получим:
Как видим LATERAL соединение позволяет для каждой записи главного запроса вызвать указанный подзапрос (или хранимую процедуру, в которую можно передать в качестве параметров поля главного запроса). Не знаю как у других СУБД с поддержкой такого соединения, знаю, что в Юконе вроде как планировали тоже такое сделать (кстати лучше им сделать, реально можно и многие аггрегирующие сложные запросы через это соединение неплохо разруливать на оптимизаторе - ASA например использует для такого соединения специальные алгоритмы и подзапрос разворачивается и выполняется в корневом плане с удовлетворительной скорость, в отличие от subquery, которые реально бы подтормаживали).

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