Имя: Пароль:
1C
1С v8
Быстро получать данные из регистра другой базы
, , ,
0 vfire1000
 
22.11.17
11:17
Добрый день.
Есть задача сохранять изображения. База сервеная.
Хранить в боевой базе не хочу, админы не хотят хранить на шаре.
В итоге делаю еще одну базу (база-фото). У неё веб-сервис.
При сохранение изображения в боевой, отправляю изображение в базу-фото. В боевой сохраняю идентификатор изображения из базы-фото.
Вопрос, как хранить идентификатор в базе-фото?
Строка или на каждое изображение создавать элемент справочника или реквизит с типом "УникальныйИдентификатор" или как нибудь еще что-то
1 Волшебник
 
модератор
22.11.17
11:19
Как угодно, только проиндексируй
2 Fram
 
22.11.17
11:19
Проделал столько работы и уперся в выбор идентификатора? :)
3 lodger
 
22.11.17
11:20
УникальныйИдентификатор в запрос не запихнуть, например.
а конвертнуть в строку - и суй сколько лезет.
4 GANR
 
22.11.17
11:21
Можно взять MD5 от фото и на его основании сгенерировать ссылку справочника, можно в регистре сведений сделать измерение типа строка 36 символов и проиндексировать. Вариантов реализации масса.
5 vfire1000
 
22.11.17
11:26
(2) Еще не проделал ничего )
(4) понятно что масса. Хочу максимально быстрый
6 Рэйв
 
22.11.17
11:28
(5)Сделай строковый УИД, в чем проблема то?Быстрее чем со строками только работа с числами
7 Остап Сулейманович
 
22.11.17
11:33
+ (6) Тем более на фоне передачи между базами данных изображения - затраты на генерацию любого суррогатного индекса  будут ниАчем.
8 vfire1000
 
22.11.17
11:34
(6) я думал УникальныйИдентификатор быстрее будет, но (3) говорит что не взлетит в запросе
9 Волшебник
 
модератор
22.11.17
11:34
(5) Вот тебе решение:

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

И регистр сведений с измерением "Фото" (типа справочник, проиндексирован) и ресурсом типа "ХранилищеЗначений"
10 Рэйв
 
22.11.17
11:37
(8)Так и юзай УникальныйИдентификатор, только приводи его к строке. Тогда и запрос его будет кушать
11 GANR
 
22.11.17
11:39
(9) Очень хорошо - такое решение позволит быстро получить выборку ссылок на фотки. Только лучше Код использовать в качестве реквизита ID - не надо аппендиксы оставлять.
12 Остап Сулейманович
 
22.11.17
11:41
(8) С точки зрения СУБД - УникальныйИдентификатор - подмножество типа CHAR. Но с фиксированной длиной в 36 штук. И быстрее будет только в том смысле, что нет необходимости каждый раз вычислять реальную длину строки. На фоне обменов данными изображения - ниочем.
13 Остап Сулейманович
 
22.11.17
11:43
+ (12) И вообще. Раз уж принято хранить изображения в другой базе - я бы сразу хранил их в скульной. Зачем прокладка из 1С - мне не понятно.
14 Волшебник
 
модератор
22.11.17
11:43
(11) можно и код
15 Волшебник
 
модератор
22.11.17
11:44
(13) тоже верно
16 vfire1000
 
22.11.17
11:47
(13) действительно, зачем ) что-то я не туда пошел. Спасибо
17 d4rkmesa
 
22.11.17
15:36
(16) Я бы попробовал noSQL СУБД. http://catalog.mista.ru/public/642927/ здесь пример работы с MongoDB через RestHeart. Мучать реляционные SQL СУБД файлами нехорошо. =)