«О бухгалтерии. Часть 12. Алгоритмы. Много данных»

­­­­­­­­­­­... то есть BigData :)

я обещал рассказать про ситуации, где без программ вроде 1С или Паруса реально не обойдёшься.  Могу вспомнить  такую ситуацию. Просили состыковать 1С с кассовым аппаратом. Я не смог и не стал углубляться, т к там не помню, с какой-то стороны, то ли с стороны 1С, то ли со стороны машинки, не было "мануала" от слова "совсем". И это было от небольшого предпринимателя в арендованной комнате завода. И программы были не куплены. Ситуация типичная. Говорят, что кассовые аппараты (а они - реально работают) в России были часто состыкованы прямо с 1С. Не знаю, насколько это актуально для Кыргызстана, это мне расскажете ВЫ.

Теоретически, при регистрации большого количества данных нужна "взрослая" СУБД, а не карманная вроде хвалимого мной ACCESS. Меня здесь больше всего интересует вопрос надёжности именно регистрации. Хотя есть и другие большие вопросы, связанные с обеспечением (хоть как-нибудь) теледоступа к этой регистрации в больших обьемах. Здесь предпочитаю быть осторожным, и это ещё одно, про что будете рассказывать ВЫ. Движок базы данных, над которым стоит ACCESS, по моему опыту, надёжен. Но есть чисто количественные ограничения по числу таблиц в базе и по числу строк в таблице. Ещё раз, предпочитаю быть крайне осторожным. Как и большинство совковых разработчиков, я много лет потратил на возню с негодными инструментами (имею в виду семейство PRG DBF без DBASE V - пятая версия не дошла).  С переменным успехом, в основном с успехом, но это же никуда не годится. Как стало очевидно потом.  После перехода по совету коллег на другой инструмент производительность выросла в разы, ошибки практически исчезли, "пожарные" вызовы к заказчикам (а это - бухгалтерия, зарплата) прекратились совсем. Года за два я запустил (и без срывов) больше систем, чем до этого за пять. Факторы: 1) программирование НЕ на процедурно-ориентированном алгебраическом яыке программирования 2) надёжность... просто пригодность! движка базы данных. Ориентируюсь ТОЛЬКО на такой конкретный опыт конкретных коллег, которому (и которым) можно доверять.

Надёжен от слова "совсем". Разрабатывался тренажёр авиадиспетчеров. Информация о воздушной обстановке поступает в реальном времени. Обсчёт и визуализация тоже в реальном времени. Что-то штук 20 (до 50) рабочих мест диспетчеров, с 1-2 экранами на каждом.  Система делалась последовательной доводкой макета. Поскольку обьем условно-постоянной информации (характеристики ВС) довольно большой, и довольно часто нужно менять данные о зонах полётов - решили предварительно использовать ACCESS, который был, в котором готовые средства модификации таблиц были, чтобы на начальном этапе не заниматься front-ом к БД. Это "предварительно" оказалось пригодным не только для макета, но и для реальной работы (в реальном времени в моделировании большого аэропорта, зон руления и полёта, сотен ВС и маяков, с многими терминалами). Динамическая модификация таблиц в реальном времени делалась с помощью штатного программного интерфейса ACCESS к базе (часто используют SQL-запросы из программ). Тренажёр состоял из различных модулей обсчёта, визуализации и т.п., а обмен между модулями делался очередями запросов. Всё, что "не база", было написано на C и VB (это как раз процедурно-ориентированные алгоритмические яыки программирования).  То есть - движок JetEngine продемонстрировал надёжность. Ни о какой "бухгалтерской" технологии речь не шла, использовался невидимый бухгалтеру движок как бы бухгалтерской базы, для обсчёта в реальном времени, back, без всякого front-а к БД. Уж если он работает в реальном времени, будет работать и с бухгалтерией.

В пределах количественных ограничений ACCESS.

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

Вернёмся к транзакциям. Здесь есть противоречие в самом понятии "транзакция". Мы говорили о случаях (а это распространённые случаи при применении готовых программ), когда "расчёт" делается в несколько этапов. Сначала что-то добавляется в промежуточные базы (денормализация), потом запускаются окончательные расчёты с выдачей форм. Допустим, что сбой произошёл на этапе ввода.  Уже первую часть расчёта сделали, и ошибку заметили только теперь. Что делать, откатывать там, и расчёт по новой? Или  по логике задачи это должна была быть транзакция размером в две недели?

Скажете: транзакция не для того. Она для случаев, когда сбой (незавершенная транзакция) обнаруживается и восстанавливается по журналу и очереди транзакций автоматически. Тогда вопрос, где в SQL начало и где конец транзакции, и ... спасёт ли она (локальная) непрочную технологию расчёта, который длиной в две недели и в которой этих SQL-запросов десятки, притом взаимоувязанных?

Где начало и где конец транзакции в конкретной СУБД, это к теме вышеописанного семинара.
Я сомневаюсь, что это вообще существенно влияет на задачи, связанные с логической схемой данных и с технологией. Локальная надёжность выполнения отдельной команды в совр. железе очень велика. Надёжность обеспечивают в основном хорошая схема базы данных и технология работы с программой.
Логические схемы БД - тема отдельного цикла занятий "в реале".

И третья, самая полезная тема - электронные таблицы.

Но мы ещё не закончили про противоречие и приёмы избавления от услуг "больших баз"

Продолжение следует.