Добрый день.
Есть задача сохранять изображения. База сервеная.
Хранить в боевой базе не хочу, админы не хотят хранить на шаре.
В итоге делаю еще одну базу (база-фото). У неё веб-сервис.
При сохранение изображения в боевой, отправляю изображение в базу-фото. В боевой сохраняю идентификатор изображения из базы-фото.
Вопрос, как хранить идентификатор в базе-фото?
Строка или на каждое изображение создавать элемент справочника или реквизит с типом "УникальныйИдентификатор" или как нибудь еще что-то

Как угодно, только проиндексируй

Проделал столько работы и уперся в выбор идентификатора? :)

УникальныйИдентификатор в запрос не запихнуть, например.
а конвертнуть в строку - и суй сколько лезет.

Можно взять MD5 от фото и на его основании сгенерировать ссылку справочника, можно в регистре сведений сделать измерение типа строка 36 символов и проиндексировать. Вариантов реализации масса.

(2) Еще не проделал ничего )
(4) понятно что масса. Хочу максимально быстрый

(5)Сделай строковый УИД, в чем проблема то?Быстрее чем со строками только работа с числами

+ (6) Тем более на фоне передачи между базами данных изображения - затраты на генерацию любого суррогатного индекса  будут ниАчем.

(6) я думал УникальныйИдентификатор быстрее будет, но (3) говорит что не взлетит в запросе

(5) Вот тебе решение:

Заведи справочник "Фото" с реквизитом "ID" типа строка, проиндексирован, и прочими реквизитами (сведения об изображении)

И регистр сведений с измерением "Фото" (типа справочник, проиндексирован) и ресурсом типа "ХранилищеЗначений"

(8)Так и юзай УникальныйИдентификатор, только приводи его к строке. Тогда и запрос его будет кушать

(9) Очень хорошо - такое решение позволит быстро получить выборку ссылок на фотки. Только лучше Код использовать в качестве реквизита ID - не надо аппендиксы оставлять.

(8) С точки зрения СУБД - УникальныйИдентификатор - подмножество типа CHAR. Но с фиксированной длиной в 36 штук. И быстрее будет только в том смысле, что нет необходимости каждый раз вычислять реальную длину строки. На фоне обменов данными изображения - ниочем.

+ (12) И вообще. Раз уж принято хранить изображения в другой базе - я бы сразу хранил их в скульной. Зачем прокладка из 1С - мне не понятно.

(11) можно и код

(13) тоже верно

(13) действительно, зачем ) что-то я не туда пошел. Спасибо

(16) Я бы попробовал noSQL СУБД. http://catalog.mista.ru/public/642927/ здесь пример работы с MongoDB через RestHeart. Мучать реляционные SQL СУБД файлами нехорошо. =)