Оценка востребованности релизов Clarion на февраль 2017 г.

[finsoftrz]

Есть, например, одна проблема. Если Вам надо перебрать 2 миллиона записей по одной таблице, то что? Сколько нужно ждать при работе с tps?

Думаю, не так долго. Данные дергаются не по сети и даже не с диска, а из кэша в оперативной памяти. Я понимаю, что в sql это может произойти быстрее за счет кэширования запросов. Но задача в реальной жизни не такая частая. По мере закрытия учетных периодов сохраняются сводные итоги. Программа будет дергать данные из них по мере обнаружения, а не из большого массива данных, что сократит время кардинально. Гораздо чаще приходится считывать отдельные записи. Сколько времени, к примеру, займет на sql сделать тысячу select по одной записи. Сравните с tps. Вопрос из той же серии. Тут главное понимать, что речь идет не просто о сравнении голого драйвера tps с программой под названием sql, а прикладных решений. Часть функций, обеспечиваемых sql серверами, встраивается в прикладное решения. На кларионе это хорошо реализуется с помощью шаблонов, чтобы не писать врукопашную...

[finsoftrz]

кто как рекламирует решения на sql

Здесь наверно нужно посмотреть историю. Концепция SQL возникла лет 30-40 назад, когда предполагалось,
что "тонкие клиенты" будут выполнять запросы на сервере. Это пошло в разрез с развитием операционных
систем - они развиваются как рекламные платформы с возможностью воспроизведения мультимедийного
контента. В результате сегодня "офисные десктопы" - это достаточно мощные компьютеры, способные
тянуть несколько терминальных сессий, что вполне удобно для терминальных решений без SQL.

Здесь все верно. Если плюс к вышесказанному предположить, что реальная пропускная способность
сетей выйдет на 100 MByte / сек - действительно, не нужны будут никакие SQL, да и терминальные
решения тоже. Концепция NoSQL - победит за счет простоты разработки и поддержки, к чему видимо все и идет ...

Точно так, концепция sql задумывалась не в том виде, во что это вылилось сегодня. Движение все равно идет в сторону тонких клиентов. Централизованные вычисления всегда выгоднее распределенных, если мощности серверов позволяют. Это общая тенденция. В целом, никто ведь не запрещает комбинировать использование sql серверов и терминалов. Просто в сегменте малого бизнеса это не особо целесообразно. Опять таки, терминалы тоже не золотая пуля и не догма. Например, если есть территориально удаленные точки продаж, то в них нужно обеспечить переход в режим работы offline. Иначе при проблеме с доступом к серверу встанет работа во всей сети магазинов. В такой ситуации лучше применять гибридное решение. В наших реалиях, во всяком случае...

[RaFaeL]

А почему вы делите все на терминал/sql?
У нас значимый процент клиентов работает в терминале И SQL
Еще есть вариант, когда два сервера, один под терминал второй под SQL и между ними канал гигабитный

[finsoftrz]

А почему вы делите все на терминал/sql?
У нас значимый процент клиентов работает в терминале И SQL
Еще есть вариант, когда два сервера, один под терминал второй под SQL и между ними канал гигабитный

Если вопрос ко мне, то я в предыдущем сообщении про это написал:
"В целом, никто ведь не запрещает комбинировать использование sql серверов и терминалов. Просто в сегменте малого бизнеса это не особо целесообразно".

[kreator]

А почему вы делите все на терминал/sql?

А если вопрос ко мне, то я говорю, что терминал не для работы с БД. На удалённом филиале мы и работаем в связке терминал/sql, потому что по-другому не получается. Просто finsoftrz "пиарит" связку терминал/tps как альтернативу sql, что в корне неправильно.

По мере закрытия учетных периодов сохраняются сводные итоги.

А я ничего не сохраняю. И даже не понимаю, как это сделать. В каком разрезе итоги? Итоги чего?

[Игорь Столяров]

В каком разрезе итоги? Итоги чего?

Рискну привести в качестве примера классику: опердень в банке.
Мы можем получить оборот по счету за любой период и остаток на любую дату, каждый раз тупо
просчитывая все операции по счету (такие операции любят приводить в примерах к использованию SELECT).
Но так как каждый день закрывается (рассчитывается и хранится остаток на дату по счету), то можно просто
взять остаток на нужный день и просчитать только оборот за запрошенный период и все.
При миллионах транзакций по счету мы получаем моментальный результат.

Аналогично в товарном учете. Если мы "закрываем" смену, месяц или год и храним по ним остатки товаров,
то нам не надо перелопачивать всю базу операцией, достаточно взять остаток на дату закрытия и считать
операции от него. Это конечно очень сокращает объем обрабатываемых данных, но требует определенных
правил: в закрытом периоде модификации недопустимы (или требуется потом его закрытие с пересчетом остатка),
при вскрытии закрытого периода - данные не достоверны (надо блокировать запросы) до перезакрытия.

Ну, если примерно - то как-то так ...

[finsoftrz]

Внесу маленькую ремарку. Я рассказываю про опыт работы со встроенной базой данных на терминале. Многие кларионисты работают с tps, для них это реальный способ без переделки программ сделать их работу быстрой и надежной. SQL в центре внимания только у тех, кто с ним работает. Для меня это не опция, я вообще считаю всю эту технологию ошибкой в истории развития информационных систем. Это, конечно, шутка, в которой только доля ее...

Про итоги Игорь, в принципе, правильно начал. Дополню тем, что я сохраняю не только остатки на начало периода, но и сводные обороты. В тех разрезах, которые часто используются и требуют много вычислительных ресурсов. Когда-то я давал ссылку на статью со своего сайта по этой теме. Если кратко, то такой пример. Нам часто надо получить итоги продаж в разрезе товаров поставщиков. Понятно, что один и тот же товар может приходить от разных поставщиков, по разным ценам и продаваться с разной наценкой. Закрывая период, мы сохраняем результаты расчета, включая сумму закупки, сумму продажи в разрезе поставщик/товар. Период плавающий, начинается от предыдущего закрытого периода. Например, месяц. Когда формируется отчет, считающий маржу в разрезе поставщиков и их товаров, то программа найдет эти итоги и возьмет готовые цифры, не лопатя все документы и не пересчитывая каждый раз распределение продаж по закупкам. Если наш отчет не попадает в период, за который сохранены итоги, то программа попытается сделать декомпозицию. Например, мы закрываем периоды по месяцам, а отчет за квартал. Программа возьмет готовые итоги за каждый месяц квартала и объединит результат. Если итогов за часть периода отчета не обнаружено, программа возьмет то, что есть, а оставшуюся часть посчитает перебором документов. Аналогично итоги сохраняются в разрезе покупатель/товар, товар/склад. А в бухгалтерском модуле сохраняются сводные итоги в разрезе корреспонденции счетов, после чего сводная оборотка за год строится за несколько секунд, независимо от количества документов в этом году и сложности алгоритма генерации проводок.
Механизм сохранения итогов стандартизирован. Если видим, что отчет формируется долго и это происходит достаточно часто, то подтягиваем сводные итоги. Но, вообще говоря, потребность в подобном механизме есть только для описанной ситуации с распределением продаж по закупкам, остальное и так быстро считается, начиная от остатков на конец ближайшего закрытого периода относительно периода, запрошенного в отчете.
Стоит еще добавить, что закрытие и открытие периода не требует монопольного доступа к данным и блокировки работы пользователей. Если потребовалось внести изменения в закрытый период, у соответствующей заглавной записи итогов просто снимется флажок актуальности. Вносим изменения и снова закрываем. В заглавной записи выставляем статус "считается". В таблицы итогов перезаписывается только то, что изменилось. Включаем флажок актуальности. Включать и актуализировать итоги можно пакетами. То есть, например, выключаем все итоги за год, меняем что-то в начале года в документах, актуализируем все итоги за год. Параллельно два пользователя этот процесс запускать не могут, включается механизм так называемой логической блокировки системных функций.

[finsoftrz]

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

[kreator]

Итоги - это ужас. Нужно много чего хранить и в разных разрезах. Надо ещё как-то отрабатывать ситуацию изменения чего-либо в закрытом периоде. Я сам это проходил. Просто получается, что с использованием SQL можно обойтись и без этого. И я очень рад этому. Конечно, если обороты конторы в районы нескольких миллионов проводок (позиций накладных) в год, тогда нужно подумать об этом. Может десятков миллионов. В конце концов производители SQL-серверов постоянно работают над способами увеличения быстродействия. А файл-серверная технология остановилась в своём развитии. Вот и приходится придумывать всякие обходные манёвры.
Кстати, похоже NoSQL (расшифровка - Not Only SQL) - тупиковая ветвь развития.

[finsoftrz]

Если внимательно прочитали, то сохранение промежуточных итогов используется не столько для скорости извлечения данных из базы, сколько для оптимизации скорости их последующей обработки. Распределение отгрузок по продажам задача не такая простая, как может показаться. Расскажите, как у Вас выполняется расчет маржи в различных разрезах. Я очень сильно сомневаюсь, что на sql процесс динамического расчета будет происходить быстрее, скорее наоборот. Даже при прямом переборе документов.

[finsoftrz]

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

Я думаю, у Вас была другая идеология.
1. Изменять документы в закрытых периодах нельзя.
2. Много чего хранить не надо. Только то, что значительно экономит вычислительные ресурсы и имеет сложные расчетные алгоритмы.
3. Закрывать и открывать периоды очень просто. И необязательно. Периоды могут иметь любую продолжительность. Программа использует итоги по мере их обнаружения. Если база данных небольшая, периоды можно и не закрывать годами. На крупных базах (те самые несколько миллионов строк в документах) зарывают обычно по месяцам, а открытыми держат последние 2-4 месяца.

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

[kreator]

Контора, где стоит моя разработка - два оптовых склада, 10 розничных магазинов, десяток Юрлиц (помоек, хорошо бы в их разрезе тоже иметь итоги), 50000 наименований продукции. Расчёт остатков по складам и магазинам - достаточно долгая операция. Предполагаю - нужно хранить остатки на некую дату. Это и есть итоги. Получается, что остатки на конкретную дату буду иметь несколько миллионов записей. Оно нам надо? Или я вообще не прав?

[Игорь Столяров]

несколько миллионов записей.

Да. Но это будет список с уникальным индексом (например для остатков: предприятие, склад, товар, дата),
по которому будет производится выборка. Никто ведь не собирается последовательно "лопатить" весь этот
список при каждом запросе на остатки ...

[finsoftrz]

Контора, где стоит моя разработка - два оптовых склада, 10 розничных магазинов, десяток Юрлиц (помоек, хорошо бы в их разрезе тоже иметь итоги), 50000 наименований продукции. Расчёт остатков по складам и магазинам - достаточно долгая операция. Предполагаю - нужно хранить остатки на некую дату. Это и есть итоги. Получается, что остатки на конкретную дату буду иметь несколько миллионов записей. Оно нам надо? Или я вообще не прав?

По складам и магазинам надо, по юрлицам скорее всего нет. Последнее нужно чисто для бухгалтерии, отдельная тема. Я храню остатки не просто в разрезе товар/склад, а товар/склад/приходная накладная. Это нужно для организации ФИФО в парционном учете. Сколько будет записей в остатках, сложно сказать на вскидку. Ведь не все 50 тыс позиций есть в остатках на каждом складе/магазине. У меня в одной оптовке более 100 тыс позиций в номенклатурном справочнике, объем остатков вполне умеренный...
А можете определить в Вашей системе, например, сколько маржи получилось по конкретному поставщику за прошедший квартал? А как решаете вопрос со срезом базы данных? Ведь в такой ситуации хранить операции в базе за все время клиент вряд ли захочет...

[kreator]

А можете определить в Вашей системе, например, сколько маржи получилось по конкретному поставщику за прошедший квартал?

Поставщиков нет. Контора производственная. Себестоимость продукции считается отдельно. Маржа - типа разница между себестоимостью и оптовой ценой.

А как решаете вопрос со срезом базы данных? Ведь в такой ситуации хранить операции в базе за все время клиент вряд ли захочет...

Почему нет? Какая-такая ситуация?

Да. Но это будет список с уникальным индексом (например для остатков: предприятие, склад, товар, дата),по которому будет производится выборка. Никто ведь не собирается последовательно "лопатить" весь этотсписок при каждом запросе на остатки ...

Тема складского учёта - безразмерная. Давайте отвлечёмся от хранения итогов. Допустим без итогов пока. И, допустим, у нас файл-сервер. Как посчитать остатки. Я бы пошёл по всем проводкам и раскидывал бы товар в очереди товаров. Второй вариант - идти по проводкам по индексу товара. Вы как считаете? А если итоги хранятся где-то, то второй вариант предпочтителен?