Украинския баннерная
Глобальная торговая сеть
Одним из ограничений офисной базы данных (MS Access), является ограничение на размер её файла: 2Гб, что многими воспринимается как непреодолимое препятствие для построения учётных систем развивающихся торговых сетей.
Это заблуждение в первую очередь заставляет обратить внимание разработчиков и заказчиков учётных систем торговых сетей на такого монстра как Oracle.
Однако стоимость ожидаемых затрат быстро отрезвляет заказчиков. Вложить несколько сотен тысяч долларов только в инструментарий и примерно столько же на разработку учётной системы не каждый решится. Это без учёта дальнейших затрат на последующие сопровождение и поддержание учётной системы в рабочем состоянии. Совокупная стоимость престижного владения учётной системой класса Oracle для её "счастливого" обладателя в конечном итоге может исчисляться миллионами долларов.
Учётная система на базе продуктов компании Microsoft, например, MS SQL, обойдётся почти на два порядка дешевле. При том же объёме ожидаемой пользовательской функциональности.
Почему? Ответ прост ... Грубо говоря, продукты Oracle предназначены для промышленного применения, а продукция Microsoft это ширпотреб.
Продукты Oracle гарантируют высочайшую степень защищённости и надёжности. Изначально предназначены для применения в системах управления ядерной энергетики, опасных химический производств, космической отрасли и т.п. То есть в тех областях, в которых сбой системы управления может привести к техногенной катастрофе. Возможные потери от которой несопоставимы с затратами на эту систему управления.
Предовращению последствий какой техногенной катастрофы будет способствовать и финансово оправдано использование Oracle при создании торговых сетей? Вопрос риторический ...

Показать текст полностью ...

Обратим теперь наш взор на MS SQL. Приличный клиент-серверный инструментарий для баз данных объёмом до 256 Пб. Предельный размер файла базы данных впечатляет, но одновременно заставляет задуматься о том, какое "железо" потребуется, по мере накопления учётных данных и роста торговой сети, для комфортной работы десятков, а то и сотен пользователей. Как сказал один литературный персонаж: "... вечность имеет обыкновение очень быстро проходить ...", что в нашем случае можно трансформировать в вопрос: как быстро мы исчерпаем первоначально доступный программно-аппаратный ресурс, обеспечивающий комфортную работу (а может и просто возможность работы) наших пользователей? В том, что такой момент наступит и "скорее рано чем поздно" можно не сомневаться. Специфика больших торговых сетей: огромная номенклатура; большой товарооборот и ещё больший объём регистрируемых розничных продаж. И все эти данные надо накапливать, хранить и анализировать для успешного ведения бизнеса.
Далее, стало уже общим местом и вызывает снисходительную ухмылку разработчиков попытки строить учётные системы на основе одной таблицы с огромным количеством полей. Но почему то никто не ухмыляется когда в одних и тех же таблицах хранятся оперативные и архивные данные. Разработчику так проще, а заказчик обычно о таком и не догадывается. А тем временем, из года в год, накапливаемые в таблицах базы учётные данные устаревают, довольно быстро теряют статус оперативных и переходят в разряд архивных. Архивных, но не ненужных. А в это же время процессор, "надсаживаясь и кряхтя из последних сил", исполняет SQL-запрос, "перелопачивая" горы "архивных" данных в попытке извлечь крохи нужных пользователю "здесь и сейчас" оперативных данных. И даже индексация полей в таблицах базы данных уже не справляется с обеспечением комфортности работы пользователя.
Что делать? Ответ прост ... Нужно следить за "оперативностью" учётных данных и данные, потерявшие этот статус, "сбрасывать" в локальную архивную базу данных. Например, на том же MS SQL. "Навесить" на архивную базу OLAP приложение и пусть там пара аналитиков резвится в своё удовольствие, "творя" стратегию и тактику ведения бизнеса в торговой сети.
Практика книготорговой сети из почти двух десятков довольно крупных торговых точек показывает, что объём оперативной базы данных, её обслуживающей, балансирует в районе всего то 1 Гб. И если на такую торговую сеть взглянуть как на региональную, с высокой степенью автономности, то их растущая со временем совокупность, в условиях существования глобальной архивно-аналитической подсистемы, открывает для собственника горизонт эволюции и экспансии развиваемых им торговых сетей.
Разрабатываемые Автором торговые приложения в любых своих вариантах "разбиваются" на два файла: интерфейс и данные. При этом, оставаясь в рамках файл-серверной технологии, всегда возможна "чисто механическая" замена файла данных Access на файл данных MS SQL Express (с предельным размером файла 10 Гб и распространяемого корпорацией Microsoft совершенно бесплатно). Это замечание предназначено для тех, кто считает, что два десятка торговых точек на одну региональную сеть как то маловато. Автор же считает, что в самый раз для комфортной работы. А если в регионе можно создать большее количество торговых точек, то их "излишек" предпочтительнее объединить в самостоятельную и автономную (региональную) торговую сеть. В любом случае все региональные сети будут включены в состав глобальной торговой сети собственника и найдут своё отражение в его архивно-аналитической подсистеме. А вот если и исполнение SQL-запросов "перенести в файл данных", причём не Express, а просто MS SQL, то получим классическое приложение в технологии клиент-сервер. Вот только вопрос, а нужно ли это в нашем случае?
Ещё одной перспективной возможностью является размещение файла данных на "облачном" сервисе. Но, на данный момент, отношение Автора к "облачным" технологиям такое, что размещать бизнес-данные в "облаке" сродни их размещению в социальных сетях. Как то стрёмно ...
Вот мы и пришли к тому, что предлагаемый Вашему вниманию пакет торговых приложений может стать "кирпичиком" создаваемого Вами "здания" развивающейся и растущей торговой сети. Естественно, если Вас устраивает предложенная архитектура построения развивающихся и растущих торговых сетей.
Украинския баннерная