Доброго времени суток. Кароче такая ситуация... база можно сказать самописная, ну т.е совсем не от 1с и много перепилена. есть справочник у которого есть реквизит тип - Хранилище. В хранилище запихивается Структура, которая собирается их XML(хз важно или нет). Вот этих элементов прибавляется в день 2к-3к и следовательно табличка распухает до 4гб за пару месяцев. Можно ли как то это оптимизировать? Пока обхожусь удалением не нужного, но чувствую пора что то менять ))

sql

(0) Сжимай хранилище

(0)[Можно ли как то это оптимизировать?]
ну да, можно
- удалять не актуальные
- хранить порнуху во внешних файликах/СУБД

(1) Причем здесь sql?

(3) Буквосочетание xml из (0) видимо не привлекло твоего внимания :))

Храни XML в папке.
В хранилище пихай ссылки.

(6) или так или SQL
у SQL насколько я знаю подобных проблем нет.
Думал может еще варианты есть...

Т.е возможность хранения различной информации в 1с это конечно хорошо, но не стоит этим злоупотреблять, и пихать туда тяжеловесный мусор без оптимизации.
Ежели все таки хочется в базе - ну хотя бы допиши функционал который будет жать хмл в архив, и уже архив в хранилище.  Жмется хмл достаточно хорошо.

(2) Думаю что количество создаваемых элементов будет расти, на сколько сжатие эффективно?

Т.е конкретная реализация зависит от того насколько часто эта информация востребована, и насколько быстро ее можно извлекать.

(10) теоретически эта инфа не нужна. Это типа бекапа отправленных в ГРКЦ электронных сообщений. т.е. храниться по принципу "а вдруг"

(9)Смотря какое - любой текст жмется очень хорошо, а учитывая то что в хмл очень много однотипных наименований то вообще отлично.
Просто возьми файл с одной из хмл и попробуй сжать архиватором.

По идее можно хранить все хмл в одном архиве, тогда сжатие будет просто супер эффективным, хотя скорость доступа возможно несколько упадет.
С другой стороны это всяко лучше чем в базе хранить.

(11) нафик их вообще в базе хранить тогда?

папочки по датам и вообще к базе не вязать

(11) тогда установи срок годности и удаляй через квартал

теоретически ЦБ может запросить копию сообщения. Видимо по этому и хранят, а в базе что бы не потерялась... я так думаю.

(11)Ну тогда я бы сделал так - пихаешь все в архив, в один архив. Он получиться довольно небольшим.
А уж сам архив можешь запихать в базу ежели уж есть такое желание.

я так и не понял, xml то архивируешь? они сжимаются на ура, Гиги в сотню метров обычно (от содержимого зависит конечно)...

для начала попробую сжатие(9), минимум правки кода, а дальше посмотрим по обстоятельствам

(16) чтоб не потерялось бэкапы делать
а хранить в базе, тем паче файловой, и иметь головняк с чисткой данных, которые могут понадобиться - мазохизм

Файл xml размером 6 мегабайт сжимается до 200килобайт.
Т.е в 30 раз.
Если все эти хмл хранить в одном архиве то думаю тысяча хмл размером 5мб займет не более 50мб.

(18) ну там не совсем XML, на основе xml создается структура с помощью рекурсивной функции. Зачем так - тайна!!! для меня. и вот эта структура и засовывается в хранилище

xml в хранилище, хранилище в ЗаписьZipФайла()

вернее xml в zip, zip в хранилище

Если данных удаляются через некоторое время,то логично писать в регистр сведений и регламентными заданиями удалять по мере потери актуальности.

(1)
+100500

(22)Ну значит эффективность архивации посчитай сам, выгрузи и попробуй вручную сжать.

(26)А чем поможет скуль в данном случае?
Пухнуть будет нисколько не меньше.

(28) у файловой есть ограничение на размер таблицы

(29)Ну насколько я понял из сабжа в ограничение топикстартер не упирается, просто заблаговременная забота о размере базы.
Так что в данном случае гораздо лучше устранить причину распухания, чем забить на причину и перейти на скуль.

(28) у скуля помоему подобных ограничений нет

в общем и целом понятно, оригинальных и необычных решений нет... чудес не бывает (

Сделай обработку чистки этой таблички с удалением/переносом в файл бэкапа всего старого и по расписанию ее запускай...

Еще можно раз это архив то и храни это в архиве, т.е. не просто xml-структура туда а сначала в zip запакуй и тока потом в хранилище...

(34) и индексов надеюсь нет по этой табличке? ))

(35) нет. тип хранилище не индексируется.

(30)> я понял из сабжа в ограничение топикстартер не упирается
>следовательно табличка распухает до 4гб за пару месяцев
- не, совсем не упирается ))

(37) упирается. просто сейчас ручками мониторим и лишнее убиваем

(34) наиболее оптимально и правильно - удалять через месяц записи с XML.
Все остальное будет в бэкапах.

(37) после первой ошибки "Превышен максимально допустимый размер внутреннего файла ...1Cv8.1CD", стали контролировать. (39) из-за роста количества электронных сообщений, боюсь что и месяц база не протянет.

(40) да хоть каждый день делайте архив и удаляйте.
Потому в противном случае - только выносить весь мусор во внешнее хранение.

за неделю база 2 гига набирает, придется похоже внешнее хранилище мутить.

(42)А что мутить то? Обычный архив. Рар, зип, или 7z в зависимости от предпочтений в папке с базой.
И работа с ним через консольные команды.
Пишется это все за полчаса.

(0) Вспомнилось. в 1с 77 в базе мой предшественник хранил ТЗ из документа (опреративная информация остатков на момент ввода документа) в ревиквзите документа.

Не помню точно как там назывался метод. Что-то вроде "сохранитьвнутр"

Вобщем база жутко тормозила. После того как убрал этот реквизит база сократилась в 100 раз.

мне просто любопытно, что это за справочник? какая информация туда добавляется по 2 штуки в день, да ещё и в хранилище

(45) --> (11) (16)

(43) лень матушка ))) да и так есть чем заняться

(0) В своё время выбирал между хранением файлов внутри базы или только ссылок на них. В итоге выбрал второе. Рост размера базы оказался критичнее.. ИМХО, храни только ссылки на файлы...

(43)>Пишется это все за полчаса.
копируется, вообще-то, еще быстрее. А вот понять и написать - отнюдь не полчаса. День-два-три.
Всегда удивляли "полчастники", полчаса копирующие готовый код.

(45) лог изменений

(48)>В итоге выбрал второе.
что использовал?

(51) Дописал свою подсистемку на УФ, для хранения файлов во ВНЕ (был закуплен отдельный сервак для этого). Вся система ориентируется на 2 главных компонента:
- Справочник ХранилищеВнешнихФайлов (где хранятся ТОЛЬКО ссылки на файлы) - то, что видит пользователь. Перечень файлов которые можно посмотреть, добавить, изменить;
- Справочник НастройкиХраненияФайлов (где куча настроек позволяющих автоматически формировать путь в хранилище для добавляемого файла, без участия пользователя, расширения доступные для выбора и проч.);

Главное, на что ориентировался:
- возможность быстрого добавления в хранилище нужного файла пользователем, без необходимости указывать его конечный путь (подсистема сама определяла путь хранилища, в зависимости от вида документа/справочника; при этом, путь можно строить из произвольного числа реквизитов. Например, для документа Реализация ТРиУ: Организация -> Дата (год) -> Код. На выходе получается: \\FilesServer\ООО Дружба\2013\000000011) - пользователь только выбирает файл, требуемый для добавления, всё остальное для него скрыто;
- возможность выбора из заданного перечня расширений файлов (также задаётся в настройке) и его макс. размер файла;
- синхронизация и физический перенос файлов с изменением инфы о его местоположении в ХранилищеВнешнихФайлов, в случае изменения реквизитов, влияющих на путь файла в хранилище;
- возможность управления видимостью/доступностью для пользователя в спр. ХранилищеВнешнихФайлов с помощью RLS (свой отдельный РС, аналогичный типовому);
- возможность массового добавления файлов (каждый файл обрабатывается и проверяется на корректность имени,  наличия в хранилище и т.п.);

Короче. Потратил на это где-то 4-6 дней. Зато, блин, никаких напрягов с ростом базы :)

+ делал на базе КА

(52) да, весьма интересно получилось, я б взял как шаблон ))

(49)Не пойму что ты там копировать собрался, и что копируется быстрее.
А на написание консольных команд работы с архивом не думаю что уйдет более получаса.

(48) если бы у меня был выбор, тогда внешний архив. а так первая заповедь "если работает - ничего не трогай" )

(55) >А на написание консольных команд работы с архивом
- я и говорю - скопировать еще быстрее.
А так все с рождения владеют консольными командами работы с архивом. Как же без этого. Вообще, всеми консольными командами. И конечно, что там еще изучать можно?!

(57)Не пойму что именно скопировать можно в данном случае и откуда.
А по поводу консольных команд архива - справка по командам архива хранится в папке с установленным архиватором, или банально гуглится.

(58) я так понимаю : скопировать БД в архив и удалить лишние элементы