Привет всем!
Хочу обратиться к вам за советом

"Потею" над довольно интересной задачкой - в одно хранилище надо собрать данные из 15 филиалов
По приблизительной оценке будет около 100гб и больше

Каждый филиал работает на своей БД (Postgres, Firebird), свои картотеки, свои продукты
В хранилище ето все собирается, стандардизируется и на выходе 5 кубов дла анализирования - Продажа, Покупки, Запасы - документы, Запасы-на месте, Финансы

придумали так -
в каждом филиале ставим MS SQL Express, в центре - MS SQL Standard,
на центральном сервере для каждого филиала своя БД, между ними идет репликация данных
и отдельно - БД - хранилище данных - kuda собираються даные в таблицы фактов, таблицы измерений


Пока что на таблицах нигде нет ключей

Подскажите на что обратить внимание при таком большом объеме данных,
может даже стоит что-то сделать по другому, первый раз собираю все в одну кучу :(

Очень боюсь что в конце, когда вроде все построенно, получиться большой "БУМ" и все рухнет

maxol67eleonora,

а кубы у Вас на MS Analysis Services будут?

конечно, 2008

Dmitry BiryukoveleonoraПодскажите на что обратить внимание при таком большом объеме данныхна файловую систему: больше быстрых дисков и раскидывание таблиц по дискам

проверю - на сервере два диска - на одном система , на другом базы sql
а takoe можнo сделать v standarde?


а что с ключами/индексами таблиц надо сделать?

еще довольно неприятная вещь - после прохода пакета переброса данных с базы одного филиала (10Гб) до хранилища (13гб) файл лога вырос до 46Гб
можно ли как то избавится вообше от него? что бы операции не записывались в log

Bigheadman- Только одна группа мер
- Партицирование
- Перспективы
- Custom Rollup
- Write Back
- Data Compression - может быть критично, если ограничены в дисковых ресурсах

Мда, невесело
но нас поставили перед фактом - работаем со standardom

в измерениях обязательно ли, что бы ключи были по integer? картотеки в основном текстовые

Voyager_lan
почитать тут
и
тут

спасибо огромное


Полковник
Сурогатные ключи (int) должны быть обязательно, это даже не обсуждается -

Опыта у меня всего полгода в этой области , пока всему еще учусь - поэтому извините за простые-глупые вопросы

на курсах не акцентировалось внимание на такие клучи, пожалуйста - ткните носом в хорошую статейку на эту тему

Полковникeleonora,

Репликация данных? Что прям самая настоящая репликация? Если так - откажитесь от нее. Работайте через промежуточные файлы - с одной базы выгружаете, в другую загружаете...


А почему нет?
как тогда обеспечит пересылку данных в центр? писать дополнительные "промочки"

Полковникeleonora,

Книжка у меня есть в электронном виде, могу прислать на почту.

да, пожалуйста пришлите - eleonoras@hotmail.ru

СоветВ данном случае надо заплатить денег профессионалам хотя бы на этап обследования и подготовки ТЗ с архитектурой системы.
И опыт неоценимый получите и решение будет рабочим.

вот я и обратилась к СПЕЦИАЛИСТАМ ;)

ТЗ написано, разрисовано
только воплощая его в жизнь задумалась над некоторыми аспектами, стараясь понять и может быть улучшить предложеное
Пока сам не начнешь делать - опыта не прибудет.

не понятно почему отбрасываете репликацию данных? - ведь тогда задействованы механизмы MS SQL и не надо мучится и писать "примочки" выгрузки-загрузки

если филиалы уже работают на каких-то БД, то наверное не имеет смысла ставить рядом еще SS. надо сразу выгружать файлы и отправлять их в центр.
Конечно работают на своих БД - PostgreSQL,Firebird, dbf
а какие механизмы вы тогда используете что бы это работало без вмешательства человека?

из опыта подскажите - как лучше стандартизировать данные - под этим понимаю что -то такое - филиалы используют svoi системы ERP, свои картотеки клиентов/продуктов - а анализировать хотят общие данные - как вы решаете такую проблему?

Дедушкаeleonora...Каждый филиал работает на своей БД (Postgres, Firebird)...
в каждом филиале ставим MS SQL Express...
Скажите, а как вы предполагали переносить данные из первичных учётных систем филиала (на Firebird, например) в SQL Express?

ODBC, sqlcmd