|
Быстро получать данные из регистра другой базы | ☑ | ||
---|---|---|---|---|
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 СУБД файлами нехорошо. =)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |