«О бухгалтерии. Часть 14. Алгоритмы. Тех.приёмы. Примеры и развлекуха.»

­­­­­­­­­­­­Продолжая тему "так устроен диск".
Практически невероятно, чтобы он записал полсектора а то и пол-оборота, даже при потере питания.
В совр. дисках это могут быть многие мегабайты.
Отсюда работающая техника обмена данными между программами: через файл.
Plain-файл TXT с цифрами в текстовом виде, для удобства отладки :)
С помощью такого файла может быть организована даже очередь.

Если сверху хороших схем и софта железа навешен ещё и удачный софт оси, и удачный движок базы данных, то многопользовательская система становится на удивление крепкой, невозможно поверить, насколько непотопляемой. Применял СУБД со штатными механизмами мультидоступа к ресурсам и транзакциями. Были критичные проблемы с занятостью базы, когда уже и машина перезагружена, и никто эту базу не занимает. В сам файл, что ли, писался признак... А поверил в поддержку мультидоступа и сделал из работавшей однопользовательской программы многопользовательскую якобы просто выбором режима. Что делать ... С горя отключил тот режим, благо, он был внешним по отношению к программе. И к огромному удивлению, заработало без режима мультидоступа. В номинально монопольном режиме пара десятков терминалов простых бухгалтеров, которые не осторожничают. У каждого своя идентичная копия программы монопольного доступа:). Начисление бюджетной зарплаты примерно 20 организациям + стыковка с другими бухг. подсистемами. И работает, кажется, и по сей день с 2002 года . Но только во вполне определенной версии виндоус с вполне определенной поддержкой сети. Более или менее понял, почему так.

Конечно, вопросы логики целостности базы данных решались не упованием на штатные навороты СУБД, а там же, где и  проектировалась логическая схема базы данных (то есть на хорошем листочке бумаги). То есть совсем уже глупых, провоцирующих разрушение БД решений не принималось. Возможность мультидоступа закладывалась на уровне логической схемы БД.

Насчёт TXT файлов. Это забавно. 
По ходу встречались движки базы, где данные так и хранятся в текстовом виде, даже не CSV (упоминалось ранее), а во вполне удобочитаемом XML. КПД такой записи процентов 50, но всё равно как-то работает!

К этой же теме. Привычный поиск подстроки на совр. обоорудовании работает весьма быстро. Минимально не-лобовой алгоритм поиска - ну очень быстро. Где-то в самом конце 90-х был в ситуации, когда автомобиль искался в базе данных размером в мегабайты столько же времени, сколько форматировался весь диск (т е с заполнением 7F каждого байта каждого блока большого диска).

То есть нам надо чётко понимать, что навороченные способы хранения данных, все эти деревья и т п, могут быть всего лишь атавизмом, доставшимся в наследство от 70-х и, возможно, 80-х гг.  Нам нужно, чтобы  решалась НАША задача.

Одна из тем моих семинаров - численные методы. В частности, метод конечных элементов в расчёте конструкций. Классический древний почти докомпьютерный подход ведёт к решению СЛАУ с ленточной матрицей. Обсуждаем способы экономии памяти для решения. Находим. Бывает интересно, когда начинаем оценивать потребности в памяти для "лобовых" алгоритмов и даже не слишком ленточных матриц:). Оказывается - древние приёмы экономии уже на грани того, что они не нужны.

(Замечание в скобках. Что-то мало на каких сайтах поиск работает правильно. Наверно, копипастят одну и ту же подпрограмму:)

Если вы сами программируете сортировку, то метод "пузырька" рулит. Хотя сейчас есть уже алгоритмы чуть ли не с линейной сложностью, и даже фиксируются рекорды скорости.

Что делать, если это всё "неудачное"?
Тем более, если это не вы разрабатывали бухгалтерскую программу. 
Делать копии ("бэкапы")
(Конечно, если вы не сам хозяин, можете прикрыть ж. и сказать, что это в датацентре или в облаках не сделали бэкап, я не виноват).
А если эти данные ваши, то вот технология, как делать бэкап.
Заводим, допустим, 10 носителей
Копируем раз в день или через другой определеный период времени, или после каждого существенного изменения
- на очередной носитель, и ставим на нём дату.
Например, сегодня на 1-й, завтра на 2-й и т.д.
Вот уже заполнен 10-й, куда копировать?
Теперь снова копируем на 1-й, а 10-й кладём в АРХИВ и больше никогда его не трогаем.
Взамен выбывшего 10-го кладём в пачку новый.
- Только это НЕ пачка! Их надо хранить в существенно РАЗНЫХ местах!

Кто этого не делает, тому боги информации неминуемо дадут тааааких ... лей :)

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

Развлекуха и здесь. Случай из жизни.
Не грузится база данных автогражданской ответственности.
Механизм работы вируса.
Вирус прописывается в загрузочные области диска вне файловой системы. Шифрует данные на диске от его конца к началу. При чтении програмамми расшифровывает, при записи зашифровывает. Когда дошифрует до самого себя, затирается. Алгоритм шифрования содержится в самом вирусе, т е при затирании вируса он пропадает. Многие помнят эту знаменитую штуку.
Давайте бэкап. - Есть бэкап!
Но после сброса он не читается. Бэкап делался программой из состава СУБД, которая работает  с диском самостоятельно в обход вирусного перехвата, т.е. бэкапировались зашифрованные данные.
Теоретически расшифровать можно, шифр не криптостойкий. Готовых средств на тот момент не было, сделать расшифровку своими силами не смогли.

Предлагаются разные антивирусы. У меня тоже стоит ... нельзя же совсем без антивируса:). Только из этих соображений.
А также где-то лежит вирусный HTML-код, который для загрузки вируса обращается наружу. Извлечён с прошлого хостинга нашего сайта. Был добавлен там на несколько страниц сайта.  Не полиморфный. Лет десять с момента обнаружения и по сей день не опознаётся никакими встреченными антивирусами.
А было же ещё такое мат.обеспечение: генератор полиморфных вирусов :). То есть по сигнатуре они не ловятся.
Также актуально: ссылка на вирусный код может прописаться в один из многочисленных списков винды, по которым она загружает служебные программы. Таких мест много. Далеко не только один CONFIG.NT.  Например, содержимое некоторых показывает EmsiSoft HiJack Free.
Также актуально: вирусный код может быть абсолютно легально прописан с привычно безвредного сайта в пользовательском режиме в место типа "МоиДокументы" в файл со специальным именем, который стартуется той или иной прикладной программой (вероятно, её конфигуратор). И всех этих многообразных вариантов, полагаю, ни один HiJack не знает. И существование такого файла конфигурации в инструкции к этой программе не описано. А есть! Увы, вот это тоже совсем с натуры.
Вирус, соответственно, может портить именно прикладные данные самой зараженной програмы, т е не контролируемые системой  данные.
Этого добра мне встречалось крайне мало, но вот похоже, сейчас на не рабочем, "интернетном" компе активна приблуда, которая портит именно нотную запись. Кому-то где-то это было нужно ... Не мешает...

Возможно, бэкап не спасёт.
Чтобы он был эффективным, желательно делать его как раз в текстовом формате, который может быть прочитан глазами.
А ещё лучше, ВМЕСТЕ с бэкапированием (и это правильно) -
физически не подключать рабочие компы к интернету и интранету организации; физически отключить все места, где может быть подключен внешний носитель.

Обмен опытом по использованию антивирусов (а не только "движков" баз данных) также планируется в семинаре "в реале", примерно с июня.

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