Размер файлов btrieve

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 15:24

kreator писал(а):
13 Январь 2019, 14:36
В больших базах есть возможность разбить хранилище на несколько файлов. Типа хранение данных и индексов отдельно, что улучшает производительность. Вроде где-то читал такое. Хотя сейчас больше актуально всё засунуть в память или в кэш.
Кстати, ровно наоборот, судя по noSQL базам. Там предлагается хранение всех необходимых данных вместе с индексом. В результате достаточно выполнить поиск в порядке индекса и сразу получить всю необходимую информацию. Если индексы отдельно, то надо еще читать запись с данными по ссылке в индексе.
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4003
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 17:36

finsoftrz писал(а):
13 Январь 2019, 15:20
И пока у меня складывается мнение, что никакими ухищрениями ситуацию не выправить, надо переходить на учет по средним ценам, отказавшись от ФИФО
Ситуация с FIFO подмечена правильно. И мы уже обсуждали её решение. Оно очевидно и придумано в банковских оперднях.
Закрытие периода (день, месяц и т.д.) с расчётом исходящего остатка товаров в закупочных ценах.
И оперативный расчёт FIFO с этой точки, а не по всему массиву документов. Вот и всё. :)

Т.е. если у меня есть такие точки (остатки) на каждый день - то расчёт FIFO за любой период будет практически моментальным.
Но конечно появляются требования культуры документооборта по изменениям "задним числом". Надо потом закрывать периоды
с пересчётом остатком (что кстати удобно для протоколирования - всегда видно кто, что и с какой даты менял).
«V» значит Вендетта !

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 20:54

Уточнил. Приходов около 15 тыс накладных в месяц. Проблема с падением производительности связана с фиктивными партиями. То есть это продажи "в минус". Они накапливаются в точках остатков. Это может быть пересортица. Или весовые товары. Завозят один вес. Весы в магазине не точные, отрезают, взвешивают часть. Потом оказывается, что продали больше, чем привезли... В одиночных магазинах с этим можно бороться инвентаризацией. Приходуем все минуса накладной на начало периода, затем списываем излишки по учету (после инвентаризации). А когда магазинов много, все гораздо сложнее...
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4003
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 21:10

finsoftrz писал(а):
13 Январь 2019, 20:54
Потом оказывается, что продали больше, чем привезли...
Это общая проблема всех продуктовых магазинов. Достигается настройкой розничных весов. :idied:
«V» значит Вендетта !

Аватара пользователя
RaFaeL
Ветеран
Сообщения: 855
Зарегистрирован: 24 Март 2009, 17:59
Откуда: НН
Контактная информация:

Размер файлов btrieve

Сообщение RaFaeL » 14 Январь 2019, 0:52

Это вообще не проблема. Проблема будет, когда продавать будут меньше, чем привезли. А так только прибыль! )

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 14 Январь 2019, 10:19

Игорь Столяров писал(а):
13 Январь 2019, 21:10
finsoftrz писал(а):
13 Январь 2019, 20:54
Потом оказывается, что продали больше, чем привезли...
Это общая проблема всех продуктовых магазинов. Достигается настройкой розничных весов. :idied:
И не только. Проведением регулярной инвентаризации в том числе. Это не вопрос информационной системы. Наш вопрос в том, что в имеющихся условиях этого нет, в результате чего падает производительность системы в результате накопления кривых партий. Если уйти с фифо на средние цены, то такого не будет, остатки всегда в разрезе товар+склад.
Рязань решает.

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 19 Январь 2019, 12:56

Попробовал расчет по средним ценам. Компьютер i5 3.3 GHz, 8 ГБ ОЗУ, win7 64 разряда. База pervasiveSQL, формат 9.5. Номенклатура 20+ тыс наименований. Сеть продуктовых супермаркетов средних размеров. Расчет маржиональной прибыли по всей номенклатуре составил примерно 5 мин на прогретом кэше. По фифо за один месяц примерно 11 минут. При увеличении периода скорость еще больше деградирует из-за накопления партий.
В общем, для средних и больших продуктовых сетей надо использовать расчет маржиональной прибыли по средним ценам. В общем, это и так уже было очевидно...
Рязань решает.

kreator
Ветеран
Сообщения: 3243
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

Размер файлов btrieve

Сообщение kreator » 19 Январь 2019, 13:50

finsoftrz писал(а):
19 Январь 2019, 12:56
Расчет маржиональной прибыли по всей номенклатуре составил примерно 5 мин на прогретом кэше.
Что-то из области фантастики. А сколько записей обрабатывается? Ну, скажем, проводок?
We are hard at work… for you. :)

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 19 Январь 2019, 14:04

Не понял. 5 мин - это много или мало? Мне представляется разумным значением. Сколько записей обрабатывается я не считал. Скажем, в грубом приближении порядка 1 млн в месяц. Скорость зависит не только от количества считываемых записей, а еще от размера массива, где сохраняются результаты. Плюс там еще ближайшая цена закупки подтягивается. Отмененных документов хватает,которые в итоги не включаются, но физически в базе присутствуют.
Рязань решает.

kreator
Ветеран
Сообщения: 3243
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

Размер файлов btrieve

Сообщение kreator » 19 Январь 2019, 14:44

1 млн записей - это 0.5 сек должно быть. На остальные таблицы ещё полторы-две секунды. Я опять к тому - либо переходить к нелюбимому Вами скриптовому языку, либо (если всё же он используется, и в современной интерпретации) Pervasive в топку.
We are hard at work… for you. :)

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 19 Январь 2019, 15:01

Ну, я же написал, что речь идет не про скорость чтения данных из базы, а про определенную функцию из бизнес-логики и в определенной вычислительной в среде. Иначе сравнение теплого с мягким получится.

PS. А по поводу 1 млн записей за полсекунды, может Вы не очень хорошо представляете себе, как работает sql сервер? :-)
Рязань решает.

kreator
Ветеран
Сообщения: 3243
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

Размер файлов btrieve

Сообщение kreator » 19 Январь 2019, 18:05

Ну, правильно, функция бизнес-логики. Вы посылаете серверу запрос "Рассчитать маржинальную прибыль по всей номенклатуре за месяц". Сервер при этом фетчит миллион основных записей (в проводках) и тысяч сто, допустим, других (сама номенклатура, другие какие-то справочники, сами документы, неважно). Вычислительная среда известна (i5 и Pervasive). Результат - так себе, мягко говоря. Что ещё надо представлять?
We are hard at work… for you. :)

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 19 Январь 2019, 18:51

Как минимум, еще пару десятков параметров и разрез результирующей выборки (двух выборок). И чтобы все вписывалось в единую систему, например, совмещалось по структурам с парционным учетом.

У Вас все отчеты за полсекунды выводятся? Не верю, даже если бизнес-логика так себе...

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

Кстати, если говорить про pervasiveSQL, то кларион использует только его базовые возможности. Очень многое остается за скобками, хотя, наверно, можно работать через нативные библиотеки для с, в обход драйвера.
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4003
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 19 Январь 2019, 19:22

finsoftrz писал(а):
19 Январь 2019, 18:51
если говорить про pervasiveSQL, то кларион использует только его базовые возможности
Это не совсем так (как минимум Btrieve API 25 лет и есть много разных версий), но я хотел сказать о другом.
Я лет цать назад сделал программу, в которой интерфейсная часть работа через драйвер Btrieve, а вот отчёты, по той же самой
БД в MKD формате - делались через запросы Pervasive.SQL - т.к. они сразу устанавливаются в пакете, который Вы называете Btrieve 10.
Естественно запросы с выборками PSQL для отчётов на порядок быстрее, чем лопатить те же файлы через драйвер Btrieve.
Работает до сих пор, хотя я уже не помню куда исходники засунул. :)
«V» значит Вендетта !

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1174
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 19 Январь 2019, 19:58

В том и дело, что через драйвер btrieve. Например, драйвер не поддерживает пакетное чтение записей, а запрашивает только по одной. А это могло бы значительно ускорить работу, когда надо лопатить большой объем информации. Для ip-драйвера сделали, для btrieve нет. Насколько я в теме.
И там много подобных моментов. Я когда-то давно читал обзор возможностей pervasive. При прочих равных транзакционный интерфейс должен работать ничуть не медленнее реляционного. А вот реляционный по быстродействию уступает другим sql серверам. Хотя опять таки, чего критор не понимает, это лишь одна гирька на весах...
Рязань решает.

Ответить