| 0
- 10.01.2019 - 17:39
|
Всем доброго! Ищу решение технической проблемы. В конфигурации активно используются строки неограниченной длины (хранящиеся в таблице BLOB). Таблица быстро переполняется, возникают известные проблемы. Нужно организовать альтернативное хранение этих строк. Кто что посоветует? Пока вижу вариант внешние файлы, возможно запакованные. Но хочется ещё что-нибудь посмотреть.     | | |
| 1
- 10.01.2019 - 17:41
| может, есть какие-нибудь приблуды для хранения таких объектов? | | |
| 2
- 10.01.2019 - 18:18
| (0) кроме хранения они ещё какую-то ценность представляют? Например, необходимо ли организовывать поиск в них? | | |
| 3
- 10.01.2019 - 18:45
|
(2) там хранятся крупные объекты (каждый по нескольку Мб), привязанные к справочнику, они распаковываются при открытии формы элемента справочника (то есть это что-то похожее на ДвоичныеДанные в 8.x). Поиск там, допустим, не нужен (хотя если будет возможность организовать ещё и поиск, это будет совсем чудесно) | | |
| 4
- 10.01.2019 - 18:51
| (0) А какой еще возможен вариант, если не в базе и не во внешних файлах? В оперативе? | | |
| 5
- 10.01.2019 - 19:13
|
(4) может, база данных, что-нибудь типа SQLite ? интересует практический опыт, возможно кто-то уже реализовывал подобную задачу. нужно хранить длинные текстовые строки, обычный текст, только очень длинный. | | |
| 6
- 10.01.2019 - 19:43
| (5) Текст не хранил. Хранил файлы с фото сотрудников, которые выводились на форме справочника. И файлы - сканы документов, которые открывались из формы справочника контрагентов в программе-вьювере. | | |
| 7
- 10.01.2019 - 21:10
| А по смыслу что это за строки, что с ними будет делать 1с? Для чего все это? | | |
| 8
- 10.01.2019 - 23:03
|
(6) видимо, во внешних файлах? (7) это просто очень большие текстовые строки. не хотелось бы обсуждать вопрос "зачем". хочу обсуждать вопрос "как". повторюсь, интересует практический опыт тех, кто уже решал задачу хранения данных подобного типа. | | |
| 9
- 11.01.2019 - 07:10
|
(8)не хотелось и не хотелось. Решение - как чвсто зависит от ответа на - звчем. Придумать можно много чего. В 1SBLOB тоже все хранится довольно хитро, блоками, детали я уже не помню, но приходилось извлекать оттуда прямыми запросами. Поэтому как минимум возможна эмуляция хранения 1с но в некоем своем справочнике (справочниках). А еще есть изречение "Знание некоторых принципов нередко возмещает незнание некоторых фактов" | | |
| 10
- 11.01.2019 - 09:29
| (8) Да, во внешних файлах. Была структура каталогов (ИФНС, ФСС и т.д.), где лежали файлы с именами, соответствующими ИНН организации. На Вашем месте я бы организовал пофайловое хранение для каждого элемента справочника (с синхронизацией по коду например). В простом текстовике или xml-ке. И организовать теневое копирование каталога с файлами. | | |
| 11
- 11.01.2019 - 10:27
| В 8 есть внешние источники данных, храни что угодно хоть в MS SQL или иной СУБД. В 7.7 наверно есть поделки с ADO. | | |
| 12
- 11.01.2019 - 16:07
| Цитата:
Вот вся страничка этой темы в текстовом виде скопированная в блокнот заняла менее 4000 байт. Это в один мегабайт можно закатать таких страничек штук 250. Столько текста размещается на форме элемента справочника? И это кто-то читает? Чтобы что-то решать с данными и как их хранить, надо знать, что это за данные, для чего они, и как их используют. Что поделаешь, топикстартер :) или стесняется, или дал подписку о неразглашении. Думаю, разумно было бы не хранить данные подобного типа в базе. Большие файлы, в частности — текстовые, сканированные документы, фотографии, видео ... хранить в отдельных файлах и каталогах, в базе ссылки к этим файлам. | | |
| 13
- 11.01.2019 - 16:25
| Цитата:
— Вы полагаете, все это будет носиться? — Я полагаю, что все это следует шить..." | | |
| 14
- 12.01.2019 - 12:46
|
олды есть? кто-нибудь юзал SQLite для хранения очень длинных строк? | | |
| 15
- 15.01.2019 - 16:38
|
snegopat.ru/1sqlite | |
Интернет-форум Краснодарского края и Краснодара |
