Записки автоматизатора. Профессиональная исповедь
Шрифт:
Может ли быть так, чтобы за два одинаковых автомобиля с одинаковыми двигателями, отличающихся только выбитыми на их отдельных частях номерами и находящихся в собственности и распоряжении у одного лица, нужно было платить разный транспортный налог?
Вот реальный случай. В одной партии грузовиков с завода поступили два одинаковых «КамАЗа». В их паспортах была указана мощность двигателей 184 киловатта (а в лошадиных силах мощность не указана). В паспорте одного из грузовиков оказалась ошибка в номере шасси. Грузовик остался на месте, а паспорт отправили на завод переписывать. Новый паспорт выписывали более тщательно и мощность двигателя указали не только в киловаттах, но и в лошадиных силах: 250 л с. (184 кВт).
Все дальнейшие фокусы связаны с тем, что Инструкцию по заполнению паспортов транспортных средств создало и утвердило Министерство внутренних дел и в ней нет правил округления. Поэтому завод вправе написать в паспорте то, что написал. А вот Методические
«В случае если в технической документации на транспортное средство мощность двигателя указана в метрических единицах мощности (кВт), то соответствующий пересчет во внесистемные единицы мощности (лошадиные силы) осуществляется путем умножения мощности двигателя, выраженной в кВт, на множитель, равный 1,35962 (переводной коэффициент – 1 кВт = 1,35962 л с.) (Физические величины: Справочник / А. П. Бабичев, Н. А. Бабушкина, А. М. Братковский и др.; под ред. И. С. Григорьева, Е. З. Мейлихова. – М.: Энергоатомиздат, 1991.)
При этом при пересчете во внесистемные единицы мощности (лошадиные силы) округление производится с точностью до второго знака после запятой».
Аминь. Вот фрагмент таблицы налоговых ставок.
Смотрим таблицу и обнаруживаем, что грузовик, у которого мощность двигателя указана только в киловаттах, попадает в строку «Свыше 250 л с.» со ставкой 45 рублей за лошадь. Переводим киловатты в лошадиные силы: 184 х 1,35962 = 250,17008, округляем до второго знака и умножаем на ставку.
Налог за 12 месяцев получится равным 250,17 х 45 = 11257,65 рубля.
Для грузовика, у которого мощность указана в лошадиных силах, ставка берется из строки «до 250 л с. включительно». Налог за 12 месяцев оказывается 250 х 35 = 8750 рублей.
Разница в налоге для одинаковых грузовиков составила 2507,65 рубля. Неплохо, а?
Практическим следствием этого замечательного факта становится то, что информацию о транспортном налоге в номенклатурном справочнике можно хранить только для приблизительных оценок и прогнозов. А вот информацию для точного расчета налога нужно хранить для каждого автомобиля отдельно.
Предупреждение. Пожалуйста, не забудьте, что я написал этот текст не в тот момент, когда вы его читаете. За время, прошедшее между этими событиями (хотя Событие, конечно, только то, что вы эту книгу читаете, а не что, я ее написал) многие нормативные акты по налогообложению могли неоднократно поменяться, а во многих программах одни ошибки исправили, а другие добавили. Не используйте эту книгу ни в качестве пособия по расчету налогов, ни в качестве руководства по каким-либо программным средствам.
Хочется обратить внимание читателя на один вопрос, который должен быть решен в самом начале проекта. Это вопрос о том, где хранятся, где обрабатываются и где используются данные. В зависимости от ответа результатом проектирования станут решения, принципиально отличающиеся друг от друга на уровне архитектуры.
Традиционная ошибка, которую разработчики совершают довольно часто, состоит в том, что решение этого вопроса откладывается «на потом» в надежде, что превратить локальную систему в распределенную удастся с помощью небольших модификаций. Я сталкивался с системами, реализованными таким способом, на этапе их сопровождения. Сталкивался очень больно. В системах постоянно появлялась информация, перекореженная в результате активной работы пользователей, разделенных тысячами километров и несколькими часовыми поясами, а я каждый день должен был собирать информационные пазлы, не только рассыпавшиеся, но еще и сломанные в процессе транспортировки, в каждом случае пытаясь понять, в каких местах нашей необъятной Родины и в какой последовательности были нажаты кнопочки и какие скрипты теперь нужно написать, чтобы восстановить сколько-нибудь непротиворечивое состояние системы.
Ситуация с проектированием распределенных систем вдобавок сильно затуманена большим количеством специальных терминов, сильно пугающих неспециалистов, а специалистами трактуемых совершенно по-разному. Поэтому я сначала попытаюсь сформулировать на относительно простом русском языке основные выводы для читателей, для которых специальные слова типа «коллизия», «клинч», «асинхронная репликация» мало что значат, а потом попытаюсь объясниться на специальном жаргоне с более смелыми.
Проще и удобнее всего хранить и обрабатывать информацию в одном месте, а потом передавать ее пользователям (как людям, так и другим информационным системам), расположенным во всех концах земного шара, по каналам связи. В этом случае
Рис. 7. Пример системы, работающей с удаленными пользователями
Все остальные способы работы следует использовать только в случае невозможности с нужной скоростью обрабатывать и передавать по каналам связи необходимые объемы информации в течение всего времени функционирования системы.
В гипер-суперсистемах возможны ситуации, когда для хранения и обработки информации не хватает мощностей серверного оборудования, расположенного на одной площадке, но каналы связи обладают достаточной мощностью и надежностью. В таких случаях используются синхронные распределенные системы (иначе – системы с синхронной репликацией). На уровне бизнес-логики распределенность таких систем не видна: как вас не слишком волнует, расположена база на одном диске или на многих, на одном сервере или на многих, так вам не очень важно, расположена база в одном Урюпинске или еще и в Арзамасе. И если пользователь в Арзамасе начал редактировать запись о контрагенте, то другому пользователю из Урюпинска просто придется подождать, поскольку эта запись будет заблокирована.
Собственно, блокировки будут и при использовании централизованной базы данных. Пресловутый онлайн – мечта всех управленцев – означает всего лишь уменьшение задержки при передаче информации. Кстати, если определить, при передаче какой информации нужно минимизировать эти задержки, может выясниться, что это далеко не весь массив данных. Если еще начать выяснять, какова же все-таки максимально допустимая задержка, то может оказаться, что необходимо, например, иметь актуальную информацию об остатках товара один раз в день, а все остальное достаточно обновлять раз в неделю. Так мы приходим уже к периодической репликации.
Конечно же, бывают случаи, когда задержка даже в секунды может дорого стоить (классический пример – биржевая торговля), но чаще всего управленец, требующий непременно данных в режиме реального времени, не будет ими пользоваться чаще одного раза в сутки. И возможно, эти данные ему можно предоставить и более дешевыми средствами, нежели прокладкой каналов до каждого ларька и установкой многомиллионной системы на рабочем месте каждой уборщицы. Понимание этого позволяет значительно сэкономить средства – именно так получаются вполне успешные внедрения маломощных систем в огромных компаниях. – Д. К.
Именно системам с синхронной репликацией посвящено наибольшее количество теоретических работ по распределенным системам. Но такие системы страшно дороги и относительно редки, и, если вы работаете не в корпорации уровня Газпрома, а всего лишь в небольшом холдинге, включающем пару-тройку заводов и сотню магазинов, то вряд ли вам это нужно.
Рис. 8. Пример синхронной распределенной системы
Основные проблемы с распределенной системой начинаются, когда производительности каналов не хватает, чтобы данные обрабатывались удаленно, а результаты посылались клиентам, или каналы связи не слишком надежны, а с системой нужно продолжать работать на всех площадках, даже когда каналы не работают из-за повышенной солнечной активности, пьяного экскаваторщика, перерубившего кабель, или урагана.
Собственно, не так давно «каналом связи» между двумя площадками в Москве в компании, где я работал, служил курьер, который перевозил винчестер с изменениями базы данных с площадки на площадку два раза в день.
В таких случаях пользователи на каждой площадке работают со своей местной (локальной) базой данных, а сами базы выравниваются или периодически, или когда возникает такая возможность.
Урюпинский пользователь в такой системе может хладнокровно править наименование организации в соответствии с ИНН в тот самый момент, когда арзамасец начнет изменять в своей копии той же записи ИНН организации в соответствии с названием. Эта шутка носит высоконаучное название коллизии. Понятно, что попытка свести воедино арзамасско-урюпинские результаты (то есть разрешить коллизию) вызовет определенные проблемы.