Кстати, ровно наоборот, судя по noSQL базам. Там предлагается хранение всех необходимых данных вместе с индексом. В результате достаточно выполнить поиск в порядке индекса и сразу получить всю необходимую информацию. Если индексы отдельно, то надо еще читать запись с данными по ссылке в индексе.
Размер файлов btrieve
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7390
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 15 раз
- Поблагодарили: 49 раз
Размер файлов btrieve
Ситуация с FIFO подмечена правильно. И мы уже обсуждали её решение. Оно очевидно и придумано в банковских оперднях.
Закрытие периода (день, месяц и т.д.) с расчётом исходящего остатка товаров в закупочных ценах.
И оперативный расчёт FIFO с этой точки, а не по всему массиву документов. Вот и всё.
Т.е. если у меня есть такие точки (остатки) на каждый день - то расчёт FIFO за любой период будет практически моментальным.
Но конечно появляются требования культуры документооборта по изменениям "задним числом". Надо потом закрывать периоды
с пересчётом остатком (что кстати удобно для протоколирования - всегда видно кто, что и с какой даты менял).
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Уточнил. Приходов около 15 тыс накладных в месяц. Проблема с падением производительности связана с фиктивными партиями. То есть это продажи "в минус". Они накапливаются в точках остатков. Это может быть пересортица. Или весовые товары. Завозят один вес. Весы в магазине не точные, отрезают, взвешивают часть. Потом оказывается, что продали больше, чем привезли... В одиночных магазинах с этим можно бороться инвентаризацией. Приходуем все минуса накладной на начало периода, затем списываем излишки по учету (после инвентаризации). А когда магазинов много, все гораздо сложнее...
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7390
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 15 раз
- Поблагодарили: 49 раз
Размер файлов btrieve
Это общая проблема всех продуктовых магазинов. Достигается настройкой розничных весов.
За теми кто отстал - не возвращаться. (С) Кодекс
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1378
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 7 раз
- Поблагодарили: 1 раз
- Контактная информация:
Размер файлов btrieve
Это вообще не проблема. Проблема будет, когда продавать будут меньше, чем привезли. А так только прибыль! )
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
И не только. Проведением регулярной инвентаризации в том числе. Это не вопрос информационной системы. Наш вопрос в том, что в имеющихся условиях этого нет, в результате чего падает производительность системы в результате накопления кривых партий. Если уйти с фифо на средние цены, то такого не будет, остатки всегда в разрезе товар+склад.Игорь Столяров писал(а): ↑13 Январь 2019, 21:10Это общая проблема всех продуктовых магазинов. Достигается настройкой розничных весов.
C6/C11, ШВС, tps/btrieve.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Попробовал расчет по средним ценам. Компьютер i5 3.3 GHz, 8 ГБ ОЗУ, win7 64 разряда. База pervasiveSQL, формат 9.5. Номенклатура 20+ тыс наименований. Сеть продуктовых супермаркетов средних размеров. Расчет маржиональной прибыли по всей номенклатуре составил примерно 5 мин на прогретом кэше. По фифо за один месяц примерно 11 минут. При увеличении периода скорость еще больше деградирует из-за накопления партий.
В общем, для средних и больших продуктовых сетей надо использовать расчет маржиональной прибыли по средним ценам. В общем, это и так уже было очевидно...
В общем, для средних и больших продуктовых сетей надо использовать расчет маржиональной прибыли по средним ценам. В общем, это и так уже было очевидно...
C6/C11, ШВС, tps/btrieve.
-
- ✯ Ветеран ✯
- Сообщения: 4994
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
Размер файлов btrieve
Что-то из области фантастики. А сколько записей обрабатывается? Ну, скажем, проводок?
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Не понял. 5 мин - это много или мало? Мне представляется разумным значением. Сколько записей обрабатывается я не считал. Скажем, в грубом приближении порядка 1 млн в месяц. Скорость зависит не только от количества считываемых записей, а еще от размера массива, где сохраняются результаты. Плюс там еще ближайшая цена закупки подтягивается. Отмененных документов хватает,которые в итоги не включаются, но физически в базе присутствуют.
C6/C11, ШВС, tps/btrieve.
-
- ✯ Ветеран ✯
- Сообщения: 4994
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
Размер файлов btrieve
1 млн записей - это 0.5 сек должно быть. На остальные таблицы ещё полторы-две секунды. Я опять к тому - либо переходить к нелюбимому Вами скриптовому языку, либо (если всё же он используется, и в современной интерпретации) Pervasive в топку.
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Ну, я же написал, что речь идет не про скорость чтения данных из базы, а про определенную функцию из бизнес-логики и в определенной вычислительной в среде. Иначе сравнение теплого с мягким получится.
PS. А по поводу 1 млн записей за полсекунды, может Вы не очень хорошо представляете себе, как работает sql сервер?
PS. А по поводу 1 млн записей за полсекунды, может Вы не очень хорошо представляете себе, как работает sql сервер?
C6/C11, ШВС, tps/btrieve.
-
- ✯ Ветеран ✯
- Сообщения: 4994
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
Размер файлов btrieve
Ну, правильно, функция бизнес-логики. Вы посылаете серверу запрос "Рассчитать маржинальную прибыль по всей номенклатуре за месяц". Сервер при этом фетчит миллион основных записей (в проводках) и тысяч сто, допустим, других (сама номенклатура, другие какие-то справочники, сами документы, неважно). Вычислительная среда известна (i5 и Pervasive). Результат - так себе, мягко говоря. Что ещё надо представлять?
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Как минимум, еще пару десятков параметров и разрез результирующей выборки (двух выборок). И чтобы все вписывалось в единую систему, например, совмещалось по структурам с парционным учетом.
У Вас все отчеты за полсекунды выводятся? Не верю, даже если бизнес-логика так себе...
Почитайте форумы, посвященные учетным системам масштаба предприятия. Что-то нет там такого волшебства. Одно дело, когда рассуждаете, а вот сколько времени стоит прочитать записи, другое, когда сталкиваетесь со сложными реалиями и когда надо решить поставленную задачу еще вчера. Вот тогда и начинают лезть из всех углов глюки, тормоза, выпученные глаза у пользователей и разработчики на sql с валидолом под языком...
Кстати, если говорить про pervasiveSQL, то кларион использует только его базовые возможности. Очень многое остается за скобками, хотя, наверно, можно работать через нативные библиотеки для с, в обход драйвера.
У Вас все отчеты за полсекунды выводятся? Не верю, даже если бизнес-логика так себе...
Почитайте форумы, посвященные учетным системам масштаба предприятия. Что-то нет там такого волшебства. Одно дело, когда рассуждаете, а вот сколько времени стоит прочитать записи, другое, когда сталкиваетесь со сложными реалиями и когда надо решить поставленную задачу еще вчера. Вот тогда и начинают лезть из всех углов глюки, тормоза, выпученные глаза у пользователей и разработчики на sql с валидолом под языком...
Кстати, если говорить про pervasiveSQL, то кларион использует только его базовые возможности. Очень многое остается за скобками, хотя, наверно, можно работать через нативные библиотеки для с, в обход драйвера.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7390
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 15 раз
- Поблагодарили: 49 раз
Размер файлов btrieve
Это не совсем так (как минимум Btrieve API 25 лет и есть много разных версий), но я хотел сказать о другом.
Я лет цать назад сделал программу, в которой интерфейсная часть работа через драйвер Btrieve, а вот отчёты, по той же самой
БД в MKD формате - делались через запросы Pervasive.SQL - т.к. они сразу устанавливаются в пакете, который Вы называете Btrieve 10.
Естественно запросы с выборками PSQL для отчётов на порядок быстрее, чем лопатить те же файлы через драйвер Btrieve.
Работает до сих пор, хотя я уже не помню куда исходники засунул.
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4638
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
В том и дело, что через драйвер btrieve. Например, драйвер не поддерживает пакетное чтение записей, а запрашивает только по одной. А это могло бы значительно ускорить работу, когда надо лопатить большой объем информации. Для ip-драйвера сделали, для btrieve нет. Насколько я в теме.
И там много подобных моментов. Я когда-то давно читал обзор возможностей pervasive. При прочих равных транзакционный интерфейс должен работать ничуть не медленнее реляционного. А вот реляционный по быстродействию уступает другим sql серверам. Хотя опять таки, чего критор не понимает, это лишь одна гирька на весах...
И там много подобных моментов. Я когда-то давно читал обзор возможностей pervasive. При прочих равных транзакционный интерфейс должен работать ничуть не медленнее реляционного. А вот реляционный по быстродействию уступает другим sql серверам. Хотя опять таки, чего критор не понимает, это лишь одна гирька на весах...
C6/C11, ШВС, tps/btrieve.