Задачка для MS SQL. Часть 2 – Схема баз

Начало тут.

Итак, продолжим…  Кратко пробежимся по серверам, бд, фирмам (имеется в виду логическая бд Navision, она же компания) , по их связям и специализации…

Вот тут я на коленке набросал условную схему — просьба сильно за неё не бить :)
Ниже приводится много лишней информации, избыточной для нашей задачи :)

schemaСхема отображается с масштабированием, кликните на неё для увеличения.

Условные обозначения:

— Зеленый прямоугольник — сервер SQL;
— Синий прямоугольник — SQL БД;
— Красный овал — «логическая» фирма внутри SQL БД;
— Фиолетовые фиговины :) — «внешние» системы;
— Стрелки — направления обмена;

Пояснения:

На сервере Офиса расположены начальная и конечные базы:
— Бухгалтерская — с ней всё ясно, там собираются финансовые результаты, как в виде документов, так и сумм по определенным счетам (н-р из внешних систем), там же где то ошиваются бюджеты.
— Управляющая — база где рождается вся входящия информация в системе, н-р всякие справочники поставщиков, товары, заказы покупки и многое другое. Из неё данные раскидываются практически по всем базам.

Далее идут «региональные» центры дистрибьюции или иначе говоря центральные склады, это центр приема, распределения товара и накопления промежуточных финансовых итогов с самих складов и с относящихся к ним магазинов. Так же Московский склад является источником товаров для Регионов, живущих в 1с (в 1с там тоже распределенная база со своими региональными складами и магазинами, но 1с в перспективе умрет, отдав свои магазины в Навижн или как отдельный региональный центр или как некое подмножество магазинов в московской базе), сам же 1с регионы отдаёт в Московский склад остатки своих магазинов. Обмен идёт через FTP.  Прочие ЮЛ (Юридические Лица) — это бренды  которые ещё остаются в старой системе написанной на Delphi, на смену которой и пришел Навижн. В итоге Навижен должен поглатить все прочие системы… если сам не сдохнет :)

Там же, на уровне региональных складов, где-то затерялся отдельный OLAP сервер для аналитиков :)

Уровнем ниже идут базы магазинов сгруппированные по брендам, они живут на складских серверах. Внутри каждой базы Фирмы магазинов. Основные справочники сделаны общими.

Вообще то, изначально, планировалось, что в каждом магазине будет свой локальный сервер на неSQLной нативной базе Navision. Но внедрение Навижена на первом же мелком бренде (порядка 4 магазинов)  показало, что отследить репликацию между таким кол-вом серверов и баз, которые выйдут в итоге —  задача для сумасшедшего. Не говоря уже о том, что ежедневно надо заходить в каждую базу и ставить там обновление (система постоянно дорабатывается и каждый день делается что-то новое, что надо раскидать по всем базам ручками, автоматизировать это нельзя никак).  В общем решили минимизировать число серверов и баз. Вопрос кому должно жить лучше был решен в пользу IT отдела :) Создали по отдельной базе для каждого бренда и разместили базы «у себя»  на складе, а магазинам настроили терминальный сервер, где они работают удаленно. Связь конечно так себе и частенько их работа смахивает на пошаговую стратегию…

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

Итого получается:

Наименьшая структурная единица — фирма, но она может  логически иметь одно или несколько наименований склада в самой системе (для магазина — это имя склада с ним связанного, для центрального склада это склады работающие в нем), т.е.
Склад -> Фирма -> БД -Сервер БД

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

Вот всё это явно напрашивается в общию справочную таблицу, по которой можно будет строить запросы.


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

09.04.2010 · 13-ый · 5 комментариев
Метки: , , , , , ,  · Рубрики: 13-ый, MS SQL, Navision

5 комментариев

  1. Хантер - 09.04.2010

    Репликация на таком количестве связей — дело дохлое. Если уж делать связи, то через некоторый универсальный механизм обмена документами, не зависящий от платформы и структуры базы — XML или что-то в этом роде. У меня CSV.

    В моем случае на некоторых филиалах стоит железо и софт 90-х годов, без обратной связи. То есть они просто раз в неделю пишут свою базу на флешку и везут в центр. В центре тоже не заморачиваемся, а просто ставим каждую базу в новую папку и они добавляются в супербазу. Супербаза же умеет работать с любым дерьмом. =)

    А вот между современными базами обмен идет в CSV, вернее в его разновидности от 1С, когда СписокЗначений сохраняется в файл. XML, сука, тормоз. Причем, современные базы регулярно обновляются с ИТС (чтобы были все новые налоги и буховские заморочки).

    Еще для нас была проблема — синхронизация товаров и контрагентов в разных базах. Всякие попытки навести порядок терпят крах в зародыше, единственная действенная мера — это четко проставить ИНН/КПП у контрагентов и штрихкод у товаров. Остальные номера, коды и артикулы за пределами филиала — напрасная трата времени. Каждый филиал все равно по-своему все делает. Хотя, знаю случаи, где успешно используют единые коды и артикулы, но там, как правило, сеть дистрибьюторов с зарубежными спецами в менеджменте.

    Кстати, реализовывать обмен данными через базу данных — плохой шаблон проектирования.

  2. 13-ый - 10.04.2010

    > Репликация на таком количестве связей – дело дохлое.

    Не, не дохлое, тут главно жестко прописать направления и ограничения. Если тоже делать через файлы или ещё что то, то вот тут то и дохнет… у нас обмен с OLAP сделали через CSV — жуть как медленно работает.

    > Еще для нас была проблема – синхронизация товаров и контрагентов в разных базах.

    У нас идеологической проблемы нет, у нас есть техническая проблема — используемая внешняя система (Навиженовский сервис+ утилита датадиректор обеспечивающая связь и обмен пакетами + логика в самой система = LS DataDirector) работает через жопу — вываливаются сервисы, теряются пакеты, не попадают обновления в список к передаче, отваливаются tcp порты.
    А вот использование решения на базе MS SQL репликации решает эту проблему на корню. Пока мы реплицируем только справочники. Скорее всего дальше будем придумывать что делать с остальным.

    А что касается идеалогии, то тут у нас всё просто — все справочники идут сверху вниз из 1 базы и без вариантов, в других базах стоит запрет на правку.
    Структура всех таблиц и объектов Навижн одинаковая для всех баз, т.е. все различия между базами в поведении реализуются только через настройки, логика везде одинаковая. Данные которые идут из разных мест имеют жесткие выделенные диапазоны номеров (например для операций), что гарантирует непересечение и не перетирание данных. В общем то у нас только 1 проблемный документ есть — перемещение между магазинами и складами, с ним бывают сложности и перетирания и тд. Сложность в том, что он модифицируется в разных местах, после чего возвращается в исходное место.

    > Кстати, реализовывать обмен данными через базу данных – плохой шаблон проектирования.

    Ну обмен у нас с 1С допустим — через фтп файликами, в остальных случаях у нас фактически не обмен (обмен всё же подразумевает какую-то обработку данных), а в чистом виде копирование записей базы. хотя, имхо. может быть.

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

    Кстати, появилась хорошая мысль ! Попробовать реализовать обмен документами перемещения через версии, чтоб исключить перетирания, хотя документ и фиктивный (реальными являются создаваемые отдельно для него расходные и приходные накладные), но всё равно не приятно.

    зы: Нам кстати, проще в плане поддержания целостности справочников, запретов правок задним числом и тд. У нас такой бардак в 1с и в старой учетной дельфёвой проге. А тут новая система — нельзя так сделать и всё! Это Вам не 1С, забудьте про отмену документов ! Накосячили — сторнирующий документ и не волнует :)

    Бухи кстати тоже просекли эту фишку и на радостях дали указание автоматом закрывать период разрешенного учета 3мя днями !!!

    Так что есть надежда приучить к порядку юзеров… 8)

  3. src - 15.03.2011

    Надо иметь не кривые руки, чтобы нормально работала 1С и не было никакого бардака там.

  4. src - 15.03.2011

    1С работает на ура (8.0-8.2), используйте УРБД (распределенку) и вместо Navign и тд тп. Почему бы не дописать конфигурацию 1С, разработать свою Загрузку выгрузку нужных вам данных, дописать конфигурацию таким образом…, сделать её принимающей все нужные вам данные, анализирующую все информацию, что в нее попала??? Почему бы не перевести всех на 1С наоборот? Вместо Навижн???

  5. 13th - 15.03.2011

    её (УРБД) и использовали в регионах. но то ли 1с ники у нас такие были, то ли что.. в общем не сложилось. В итоге 1С на данный момент у нас умер, осталась тока Зарплата и Кадры, да и те в течении этого года перейдут в Навижн.

Написать комментарий