Задачка для MS SQL. Часть 1 — постановка.

Дано: Сеть распределенных баз (MS Navision, он же Microsoft Dynamics NAV ) вида:

Физически — 3 сервера ms sql, на каждом сервере по несколько баз данных (магазины, склады, разные виды учетных баз).

Логически — каждая база содержит  несколько фирм/компаний. Фирмы могут иметь таблицы 2х видов — общие (одна таблица для всех компаний в базе) и таблицы для фирмы (каждая фирма имеет свой дубликат таблицы, вида —  Фирма$Имя_Таблицы).

Так же фирмы (условно так их назавем), могут быть определенного типа  — магазинами или складами (на самом деле ещё есть фирма и база бухгалтерии и некая управляющая), так же они различаются своей территориальной принадлежностью (Москва, Питер). Так же имеется имеется некое название склада/магазина связанное с фирмой (как правило это одна фирма — одно название), именно оно может использоваться для фильтрации в самом запросе (Н-р МГ001 в фирме МАГАЗИН001 ).  Эти признаки не указаны в явном ввиде в таблицах самой фирмы.

Общее число этих фирм порядка 50-70 шт.

Задача : Необходимо выполнять запросы для всех фирм сразу или для фирм отобранных по определенному критерию — склады/магазины, принадлежность — москва/питер. При этом учесть наличие как общих таблиц, для них надо выполнять не более 1 запроса к каждой SQL базе (ибо это 1 таблица), так и возможность выполнения запросов для таблиц принадлежащих фирме (структура одинакова) по их общей части (н-р маг001$Item и маг002$Item по имени Item).

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

Завтра нарисую ориентировочную структуру распределенной БД.

продолжение следует…

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

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

  1. deksden - 09.04.2010

    я бы использовал следующую систему: выгружал все данные из оперативной базы данных в аналитическую базу данных, при этом трансформировалы бы их для последующей обработки (например, объединял бы дубликаты таблиц Фирма$Имя_Таблицы и добавленем поля «Фирма»).

    Операции по добавлению кладовщика проще вести путем «ручного» кодрования алгоритма. А всю аналитическую обработку — сводные таблцы, контроль целостности и т.п. — проводить уже с аналитической БД.

  2. 13-ый - 09.04.2010

    Да в общем то так и есть, есть бухгалтерская база, куда стекаются «снизу» данные. Есть так же отдельный проект OLAP, где планируется аналитика продаж… его запуск, правда, буксует на все 4 колеса, но эта другая история.

    В данном случае скорее требуется инструмент для оперативной множественной правки данных, и составления оперативных отчетов «на скорую руку» для текущих временных задач.

    А вот что касается контроля целостности, то его проводить с аналитической базой не выйдет, проблема то у нас большая с тем, что данные по пути между базами теряются. Репликация у нас построенна на «специальном решении для Навижена» — LS Data Director. Мало того, что система оказалось весьма не устойчива (за год фирма внедренец так и не смогла обеспечить устойчивую работу этого решения), так ещё и начались проблемы с производительностью — репликация буквально захлёбывается данными, которые надо передавать.

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

  3. hunter - 09.04.2010

    У меня похожая ситуация, только базы 1С-ные и разбиты по месяцам и кварталам. В итоге получается порядка 70 баз в год.

    Я сделал супербазу, где перечислены все базы и есть средства для выборки данных из разных баз в один отчет. Очень удобно — филиал привозит флешку со свежей базой, она копируется в общий каталог и попадает в супербазу.

    Есть еще отдельные базы для бух и налоговой отчетности по разным юр.лицам, в которые данные переносятся из супербазы. С ними одна проблема — 1С-ка не тянет большие объемы документов и проводок, даже глубокая оптимизация под MS SQL не помогает. Тут уже проблема в правилах расчета налогов (с учетом партий и оплаты) когда после каждого изменения задним числом приходится все последующие документы перепроводить, а на каждый проводимый документ со множеством строк приходится огромное количество запросов и расчетов..

  4. 13-ый - 09.04.2010

    Мы только подходим к проблеме — что делать с огромным количеством старой информации? Пока ещё проблема не встала в полный рост, но ситуация уже угрожающая, за год размеры отдельных баз разрослись под 100 гб.

    Пытаемся пока бороться чисткой и оптимизацией, но чувствую что придем к отдельной архивной базе с «данными за старые периоды».

  5. hunter - 09.04.2010

    Тут дело не в архивности баз, а в их численности и разнообразии. Куча филиалов, у каждого своя база со своей структурой и заморочками. В принципе, есть две разновидности — торговля 8.6 и торговля 9.2, но бывают нюансы.. В каждой базе от 1 до 4 юр.лиц.

    А супербаза это «надстройка», позволяющая единообразно работать с кучей баз как с одной большой базой, не отвлекаясь на детали реализации каждой из них. Например, делаю отчет по клиенту «Юнимилк» — супербаза поочереди открывает каждую базу и вытаскивает документы по всем клиентам «Юнимилк» (они могут быть задвоены, разбиты по менеджерам и участкам, итд..) и собирает их в один отчет. При этом автоматически учитываются особенности каждой базы.

  6. 13-ый - 09.04.2010

    я вот это имел ввиду —

    только базы 1С-ные и разбиты по месяцам и кварталам

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

  7. Хантер - 09.04.2010

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

    Скорее, для уменьшения объема злоупотреблений задними числами. =) Каждый месяц или квартал база обрезается, задним числом уже ничего не исправить. А на уровне прав доступа блокировать бесполезно — провинциальная смекалка непобедима, все равно накосячат.

  8. hunter - 09.04.2010

    Есть другой подход, я его не смог реализовать за счет слабой обратной связи с филиалами — нужно в ихних базах изменения делать. При таком подходе данные не вытаскиваются последовательно из каждой базы, а создается файл задания и открывается несколько баз сразу, которые этот файл сами читают, обрабатывают и создают файл с результатом. А супербаза их подхватывает и присовокупляет к общему отчету. Получается распараллеливание.

    Сразу параллельно читать несколько баз не получается ввиду однозадачности 1С-ки. А параллельность формирования результата получается за счет того, что каждая 1С-ная база это не просто набор таблиц, а полноценное приложение, которое может работать автономно.

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