Добрый день

Всегда считал, что данные должны хранится как есть. 1 друг каждый год начинал базу с нуля. Я предложил ему этот год оставить как есть и продолжать работать. Для меня это полигон для тестов, но база растет и уже более 8Гб. У него 4 магазина мелких. Супермаркеты давят со всех сторон. Но у супермаркетов оборот по более будет. И явно информация о торговле хранится как то по другому.

Я сейчас написал тестовую упаковку данных вместо
780000 торговых документов остается 1460
780000 документов оплаты остается 1460
ну и товарные позиции тоже ужимаются с 1.9млн до 1млн.
База стала на 2Гб меньше.
И это только при паковке на каждый день. Для бухгалтерии такое сжатие только в плюс т.к. проводок мало становится.


1.Кто работал раньше с 1С. Они каждый документ с торгового терминала отдельно сохраняют или берется торговля за день целиком? Я сохраняю каждый документ как есть и храню.
2.Есть ли вообще смысл хранить продажи за каждый день? или упаковывать до 1 месяца? При паковке до месяца, естественно график продаж (и т.п.) не посмотришь менее месяца периодичностью.
3.Далее назревает вопрос, если с клиентами организация имеет 0 сальдо или данные устарели на 3-4 года. И подписан акт сверки со всеми об их за должности. Можно же такое сжатие сделать не только с "Частным лицом", но и с садиками (и т.п.) покупавшими в течении месяца.

Вообще думается, что 1 месяц это оптимальное решение, т.к. даже графики продаж смотрят по месячно в основном.

Поделитесь мыслями и опытом.

ExterisЕвгений БолтикЯ сейчас написал тестовую упаковку данных вместо
780000 торговых документов остается 1460 ...
Как в анекдоте, сейчас работаешь над распаковщиком?)

А зачем? Паковка по конкретному покупателю и тот "Частное лицо". Я на досуге подумал и посоветовался с другом и мы пришли к общему, что действительно нас мало волнует сколько раз покупали в этот день "Частные лица" в прошлом году(хотя я подозреваю, что и 2 месячные данные туда же). Интересует только общая сумма оплаты и что купили за день. А для статистики можно сделать 1 таблицу в которую к примеру все упакованные документы за день посчитать. А для разборов полетов существуют архивы базы.

Ivan_Pisarevskyбред какой-то про упаковку.
Надо сырец, храни сырец, надо некий укрупненный агрегат, подсчитай ночером-в_выходной и храни рядом или в сторонке.
Про 8 гиг смешно просто, прям как в анекдоте про "детские сегодня не завезли".

Если у народа нет средств на железо то, что здесь не нармального. Кому это надо тот и будет пользоваться. Лично я за оригинальный документ.
И с чего это бред. Если они даже графики продаж товара смотрят и говорят нам это не надо, мы и так знаем, что и как. Я конечно сейчас написал по дню объединение документов т.к. подозреваю когда 2-3 года пройдет начнут смотреть графики и формы анализа продаж.

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

Kirill RazuvaevЕвгений БолтикЕсли у народа нет средств на железо то, что здесь не нармального.Кхм... и во что эти 8Гб упираются? В объем диска? При вдумчивой индексации задержек видно быть не должно.

И еще: 1.9млн. товарных позиций? И при этом супермаркеты давят? :-)

1.Ну если не в курсе то такой объем для ссд подсилу, а харды загибаются. Проверено хдд 2-4мб/с, а ссд 18Мб/с пишут (ведь показатель записи реальный, только когда реальная работа не последовательной записи). Недавно у них начал глючить 1 ссд (обычно перепрошивка помогает). Отработал уже 3 год. Они поставили 2 HDD сняв их временно с видео наблюдения. Когда идет торговля даже незаметно, что работает хдд. НО когда начинается запись при обработке данных (расчет проводок и т.п. фигни) все начинает тормозить не взирая на зеркало.
2.Объем диска это не показатель работы базы. Можно купить 4Тб, но работать будет хуже 160Гб диска.
3.При поиске их и нет, только индексы и спасают. Все отчеты получаем быстро. А вот когда писать начинают пересчитывать что то вот тут пипец.

Я то понимаю делай последовательное зеркало и в 2 раза почти поднимется запись. Но надо поменять железо и докупить диски вот тут Ж. Что говорить винда даже не лицензионная стоит на компах. На сервер поставили лицензию, а дальше денег нет.

И по поводу 1.9 млн (Не вдавался как у них дела но пришлось) из них ~1млн продаж, средняя наценка 7.5% заработали около 6 млн, работало 47 человек ОФИЦИАЛЬНО. И получаем 6/47/12 где то 10000.63 руб должен каждый получить в месяц. НО есть затраты на землю, свет, налоги, оплата кредитов и т.д. И судя по тому, что в расчетке только 1 получил 13 а все остальные от 7 до 9. Чет как то не густо ЗП. А в этом году Земин(по Хакасии) хочет обязать всех поднять ЗП и счего ее подымать им. Предприниматели чахнут. Развития никакого. А теперь возмем супермаркет там от 3 до 6 касс всегда заняты, если наценка та же, то у них оборот в раз 5-8 больше (судя по занятости и объему в корзинках). Там и ЗП, и оборудование есть на, что покупать. Хотя незаметно что бы меняли.

Дома средняя запись на диск 40Мб/с. Но даже когда просят посмотреть, что то это вешалка, пока распакуешь пока то пока се. Дело не стандартной работе, а когда срочно надо или восстановить или обработать тонны записей.

Dimitry SibiryakovЕвгений БолтикНО когда начинается запись при обработке данных (расчет проводок и
т.п. фигни) все начинает тормозить не взирая на зеркало.
Руки рихтовать надо, тогда и проводки рассчитывать массово не понадобится.


Это бухгалтерам говори, а не мне. И вообще то они люди и в праве ошибаться. А программы и пишутся для них, что бы они могли свои ошибки исправить.

PS. И вообще зачем вы снова выдумываете все эти небылицы. Был бы новичок в этом деле фиг бы с ним. Лично у меня проблем нету купил железо и крути базы как хочешь. Проблемы у народа и пытаюсь как могу помочь ИМ. Не мое дело у ним в карманы заглядывать. Раз на то пошло купи им железо. Они будут счастлива, а мне по барабану у меня другие заботы.

Вам задали вопрос (нет у вас проблем нечего сказать ...) тогда может быть три варианта:
1.Молчу.
2.Не думали мы про это железо у нас супер за секунду базу 8Гб ристорит.
3.Мы делаем вот так.

Такое впечатление вы только хотите народ попинать и обидеть.

Dimitry SibiryakovЕвгений БолтикЭто бухгалтерам говори, а не мне.
У тебя бухгалтера базу проектируют? Хранимки пишут, триггера?.. Хранимые агрегаты
планируют?.. Почему-то мне так не кажется. Это ТЫ заложил такую логику, что нужно
обрабатывать по 100500 документов зараз. Это ТЫ написал процедуры, которые агрегируют
миллионы записей и перегоняют их из пустого в порожнее. Так что не надо бухгалтерами
прикрываться.


Не зная броду не лезь в воду

Сисдба МастеркеевичЧто-то непонятно. Объем 8 Гб - по истине смешной. База полностью в ОЗУ поместится и скорость диска будет влиять слабо. Да и объем оперативных данных будет существенно меньше 8 гб, тем более, тс сам же говорит, что архивные данные невостребованы почти.


Не смешно это все пока репликации нет и производства. Если бы они обрабатывали документы и ничего задним числом не правили то и фиг бы с ним. Производство не может просчитать стоимость продукции, пока не настанет день когда точно известны все затраты за месяц недостачи, свет, вода ЗП и т.д. Как только стало известно происходит расчет цены ну и соответственно, то что продавалось со склада получило складскую цену. (Это не реплицируется не надо они на уделенных базах). И не путайте цены розничные и складские. После чего надо пересчитать проводки. Эти моменты проходят на ура и достаточно быстро. Но можно ускорить процесс я увидел как и в этом нет ничего плохого.

Поместить ее можно в ОЗУ только при супере, но он нестабилен и иногда падает у одного. Соответственно все вместе с ним отваливаются. Поэтому используем классик. Еще одно НО, не я обслуживаю и они еще не разу не использовали 64 бит версию сервера, а ведь только на ней можно 8Гб объять в памяти можно.

Вообще в теме не было написано проблемы. Даже в одном ответе я дописал, ради интереса писал, что бы понять сколько данных нафиг не нужны и их можно объединить по определенным признакам. А единственный признак сколько объединено покупателей можно сохранить в отдельной таблице и то на данный момент никому не надо.

PS.Тем более друг каждый год не просто так начинает работать с нуля, им проще сопровождать свою базу. Сейчас упакованный 1 файл бакупа весит 1Гб. Делается это каждый час. Я понимаю есть частичный бакуп, но люди не хотят изучать больше чем у них есть. И я не в праве их вынуждать чем пользоваться. Тем более мое ПО бесплатное. Они не хотят сопровождения базы и сервера. Но я могу помочь по другому и это их устраивает. Если "некоторые отнесли себя к богам программирования" не согласны, то это не значит, что это не надо народу. Мне же было интересно написать и проанализировать этот момент. И еще я не настаивал это писать, друг через 2 месяца раздумий, сам позвал и спросил напишешь. Я нехотя сказал ага. Потом втянулся. Оказалось все просто.

И еще некоторые нагнетают ситуацию и топик становится зловещим. Нету там миллионов обновлений за раз. Если были бы то я бы пришел и так и написал миллионы обновлений долго как бороться. Порядка 2млн строк было из базы удалено мало значащих, а перевернули все с ног на голову.

При любых проблемах такая база это заноза в заднице. Нашим гуру, ее не пошлешь по почте выложить проблематично. Сейчас есть 10Гб база и чтобы ее проблемы решить приходится на маленьких базах эмулировать, что не всегда удается и остаются висяки, которые просто объехали по другому. Гуру сейчас заняты и 1 вещь с января только частично исправили и только в тестовом варианте, но появились и новые грабли. Я домой по городской сетке базу бакупленную и сжатую тяну 30 минут. Потом распаковка и поиск глюка. Это время и его жалко. У клиента это делать невозможно может связь оборваться и когда восстановится не понятно или железо не позволяет, т.к. зеркалка ссд 60Гб на базу отведено всего 15 Гб. А бакупы на кассовый комп делают.

krapotkinвсегда можно придумать альтернативы
у нас собираются навигационные данные по городскому электротранспорту, их тоже довольно много ))
база разбита на
1)оперативные данные о движении(все исходники за 2 недели),
2)агрегаты каждый день собираются и выносятся во вторую базу (корпоративная инфо система)
3)по истечении двух недель из первой базы отрезаются данные за один день и помещаются в архив, где хранится стопятьсот таких однодневок

все сделано как раз по размышлениям какая информация и как часто нужна
и позволяет держать БД в очень слим-размерах...
уже неск. лет в эксплуатации

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

Сисдба МастеркеевичЧто-то непонятно. Объем 8 Гб - по истине смешной. База полностью в ОЗУ поместится и скорость диска будет влиять слабо. Да и объем оперативных данных будет существенно меньше 8 гб, тем более, тс сам же говорит, что архивные данные невостребованы почти.


Да один момент не упомянул:
ГУРУ мне тут сказали по поводу
DefaultDbCachePages = 38192
нифига себе размерчик для классика. А только такой размер нам и не мешает быстро получать инфу. ;) И с этим размером есть свой глюк.

Симонов ДенисЕвгений БолтикПоместить ее можно в ОЗУ только при супере, но он нестабилен и иногда падает у одного. Соответственно все вместе с ним отваливаются. Поэтому используем классик. Еще одно НО, не я обслуживаю и они еще не разу не использовали 64 бит версию сервера, а ведь только на ней можно 8Гб объять в памяти можно.

Проблема супера не в том что он может упасть, а в том что он не поддерживает SMP (до 3.x). Да и уронить его не так то просто, разве что кривыми UDF от которых тебе ещё давно говорили избавиться. Заодно можно и на x64 перейти.

UDF давно не напрягают. Падения сервера обычно были не от UDF у меня по крайней мере и гуру не могут быстро правит, только для меня, у них и без меня проблем хватает. Сейчас конечно сервер стабильней на много, может сейчас и супер не такой падающий. И распараллеливание в 2.5 было тоже комком в горле. Я решил ждать 3 и тогда пробовать супер снова. А при базах более 2Гб я и буду рекомендовать на х64 переходить.

Сисдба Мастеркеевич> Да один момент не упомянул:
> ГУРУ мне тут сказали по поводу
> DefaultDbCachePages = 38192
> нифига себе размерчик для классика. А только такой размер нам и не мешает быстро получать инфу. ;) И с этим размером есть свой глюк.

классику не надо такой кеш ставить, он использует файловый кеш ОСи. И 32бит винда 2003 спокойно использует до 32 гб озу.


Когда всплыл один баг и после разговора с ГУРУ, я конечно начал пробовать. Когда уменьшили значение до 18192. То задержка при поиске выросла с 0.15 до 0.4 секунды пришлось вернуть как и настраивали 38192. Так что у нас получается кэш ОС не помог. Все сервера или на Вин7 или на Вин8 установлены.

Basil A. SidorovЗабавный подход. Вроде, не должно быть принципиальной разницы, что тырить.
Но, при этом, странную Windows 8 установить можно, а (уже) стабильный Windows Server 2008 (R2) - нельзя

Меня поражает утверждения по поводу W8, у меня с этой линейкой странности нету, а у банков и т.д. почему то странности, ну да ладно это не к теме. На цены W8 и 2008 глянь станет все понятно. Причем в прошлом году 4700 стоил W8 который можно было перепродавать и переустанавливать на другой комп. В этом году 8.1 и ОЕМ снова нельзя переустановить на другой комп только БОХ.