Файловых вложений может быть много даже у одного объекта. Самый популярный вариант использования вложений - фотографии для геообъектов. Обычная фото занимает ~5 Мб, в то время как метаинформация и сам объект это всего лишь килобайты. А если прикреплять видео к геообъектам? Вот и получается, что СУБД изначально спроектирована под табличную атрибутику, а по факту БД на 99% может состоять из файловых вложений к объектам. Да и регулярный бекап БД может неприлично затягиваться. Или вы используете MSSQL Express с ограничением в 10Гб на размер БД. Или же сервер с СУБД у вас общий и поэтому "захломлять" файловыми вложениями недопустимо.

В "руководстве по созданию картографических проектов" в главе "8.2. Хранение вложений как файлов на диске" указана схема конфигурационной таблицы elitegis_attachment_groups на примере PostgreSQL, где определяется как и где хранить файловые вложения для каких таблиц и классов пространственных объектов:

CREATE TABLE <my_schema>.elitegis_attachment_groups
(
  objectid serial,
  group_name character varying,
  target_table_name character varying,
  folder_path character varying,
  is_enabled integer,
  target_id_field_name character varying,
  CONSTRAINT elitegis_attachment_groups_pkey PRIMARY KEY (objectid)
)

Файловые вложения хранятся на диске в иерархическом виде. Путь до корневой папки указывается как раз в конфиг.таблице elitegis_attachment_groups, а на нижнем уровне - папка по имени равной идентификатору объекта целевой таблицы. Файлы в этой папке на диске называются ровно также, как и в ATTACH-таблице. По имени иерархии папок и имени файла идёт сопоставление и читается/пишется файл на диск.

Что выбрать в виде идентификатора объекта, вы решаете сами для каждой целевой таблицы, но это должно быть неизменяемое поле, формируемое при создании объекта. По умолчанию это PK поле objectid. Советуем для возможности миграции/слияния/пересоздания БД использовать GUID-ное поле.

Для PostgreSQL в своих проектах мы всегда его создаём с именем uid и дефолтным значением gen_random_uuid(). Для MSSQL дефолтное значение можно выставить через NEWID().

Идентификатором может быть и строковое поле - главное, чтобы было коротким и неизменяемым во всё время жизни объекта.

Конфиг.таблица elitegis_attachment_groups должна быть создана в той же схеме, что и целевая таблица с данными. Если у вас много схем в PostgreSQL, то и таблицу elitegis_attachment_groups надо создать в каждой из схем вашей БД. Теперь по полям этой таблицы:

1. поле group_name можно не заполнять, это для вашего понимания, в случае если строк будет много

2. поле target_table_name может содержать полное имя целевой таблицы (включая схему!), а также содержать символы ? и * как любой/любые символы, и кроме того быть полценоценным regexp, поэтому, если вы хотите хранить файлы на диске для объектов всех таблиц из вашей схемы, то можете указать звёздочку и обойтись одной строчкой в конфиг.таблице

3. target_id_field_name это имя поля-идентификатора объектов в целевой таблицы

4. поле folder_path это корневой путь на сервере с ГИС-сервером (не сервера СУБД!), по которому сначала будет создана папка с полным именем целевой таблицы, а внутри уже будет иерархия подпапок для объектов, поэтому folder_path логично указывать один и тот же для всех строк

5. поле is_enabled указывайте =1 как флаг актуальности настройки, и как =0, чтобы игнорировать эту строчку

При необходимости в CoGIS есть возможность "на горячую" поменять вариант хранения файлов - в БД или на диске. Например, вы хранили все вложения в БД, и решили перенести их на диск. В SOE есть настраиваемый плагин "Для администратора", который надо будет вызвать напрямую через веб-запрос /MapServer/exts/CompositeSOE/ManageAttachments?layer=...&operation=...
указав номер слоя, а также тип операции с одним из следующих значений:

1. UpdateAttachTablesByFiles - обновить __ATTACH таблицу на основе файлов на диске (удалить "повисшие" строки с несуществующими файлами, добавить строчки по новым файлами, обновить размер файлов, но сохранить и не трогать все записи с актуальными аттачментами)

2. CopyAttachmentsToFiles - сгенерировать аттачменты (blob-значение) из __ATTACH в файловой системе

3. CopyAttachmentsFromFiles - скопировать файлы (сами байты) в __ATTACH таблицу

4. DeleteAttachmentBlobs - проставить null в blob-поле в __ATTACH таблице (предполагая, что до этого было выполнено CopyAttachmentsToFiles)

5. MoveAttachmentsToFiles - выполнить последовательно CopyAttachmentsToFiles, а затем DeleteAttachmentBlobs