Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
Здравствуйте.

Попробую на пальцах: планируется БД, одна и та же структура используется, к примеру различными филиалами, с разными данными, НО с единым ядром некоторых данных для всех, т.е. под каждый новый филиал создается новая копия БД, в нее копируются данные единых справочников. Не совсем красиво, т.к. потом нужно синхронизировать единое ядро данных между базами. Один пользователь может быть клиентом любой базы.

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

Или все же нужно выносить единые данные в одну общую БД, и под каждый филиал свою собственную БД?
6 июл 15, 16:31    [17858302]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 21253
Ну вообще-то бытие определяет реализацию. Если ВСЕГДА это "ядро" будет гарантировано идентично для всех копий БД - конечно, отдельная БД разумнее. И версии тогда отслеживать проще, и обновлять проще... А вот если возможны варианты, когда это "ядро" для различных копий будет различаться (пусть и незначительно) - то надо смотреть, что выгоднее. Отдельная общая БД плюс индивидуальные модификации её, или общая БД плюс модифицирующие данные в частных БД, или без "ядерной" БД вообще...
6 июл 15, 16:36    [17858338]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8839
Гость123,

писать полноценные запросы, которые легко отлаживать и сопровождать Вы не сможете ни в одной из таких конфигураций. Наилучший вариант - отдать каждому филиалу реплицируемую, фильтрованную базу, а все информацию сливать в центральную.
6 июл 15, 16:39    [17858370]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
На отдельную единую БД не хочется идти, т.к. нельзя будет установить ссылочную целостность на нее из баз данных филиалов.

Схемы всЁ таки чем-то могут помочь в одной БД.
6 июл 15, 16:47    [17858435]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
На отдельную единую БД справочников не хочется идти, т.к. нельзя будет установить ссылочную целостность на нее из баз данных филиалов.

Схемы всЁ таки чем-то могут помочь в одной БД.
6 июл 15, 16:49    [17858447]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8839
Гость123, схемы могут помочь только тем, что Вы не попадете в ситуацию, когда одна из баз будет недоступна при выполнении запроса.

Я любом случае Вам могут потребоваться единые справочники адресов, клиентов и много еще чего. Для филиала введите атрибут "номер филиала" в требуемые таблицы. В этом случае можно будет отфильтровать данные, касающиеся конкретного филиала при репликации таблиц.
Как правило, у бизнеса возникают задачи сводного формирования отчетности, выставления счетов, складского учета и т.п. В этом случае как раз вам поможет центральная база с фильтрованными локальными базами филиалов и глобальными справочниками. Я не агитирую, это best practices для разнесенных географически филиалов.
6 июл 15, 18:31    [17858885]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость456
Guest
Владислав Колосов,

А какой тип репликации для справочников и для данных? Справочники peer to peer? А для данных филиалов транзакционная подписчик - центральный офис, а публикатор филиал? И что означает фильтрованные базы - артикли с предикатом?
6 июл 15, 19:17    [17859045]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
Присоединяюсь к вопросам Старшего ;-) Гостя

Это не географически разнесенные филиалы. Бест практик - согласен, когда реально филиалы. У меня просто в пределах одного сервера различные данные от разных источников. Согласен, что во все таблицы можно добавить ИД (филиала, источника и т.д.), наверно и секционирование по нему помогло бы. Но по каждому чиху на больших объемах юзать этот ИД, неужели ничего лучше нет?

Про схемы кто-нибудь выскажется?
7 июл 15, 09:27    [17860415]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Glory
Member

Откуда:
Сообщений: 104751
Гость123
Про схемы кто-нибудь выскажется?

Непонятны ваши цели разнесения на схемы, если они все дублируют друг друга ?
Если вам нужен шаблон схемы, то не обязательно хранить его как схему.
7 июл 15, 09:39    [17860458]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
Мне нужен не просто шаблон схемы. Мне нужны как бы независимые БД со своими данными на абсолютно одинаковых структурах, но с одним единым ядром общих справочников. Их количество может расти в будущем. Пользователь должен переключаться между этими БД.
7 июл 15, 10:08    [17860625]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Glory
Member

Откуда:
Сообщений: 104751
Гость123
Мне нужны как бы независимые БД со своими данными на абсолютно одинаковых структурах

Цель то какая ? Просто "иметь как бы независимые БД" ?
Use case-ы какие от просто имения ?
7 июл 15, 10:10    [17860636]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31990
Гость123
Это не географически разнесенные филиалы. Бест практик - согласен, когда реально филиалы. У меня просто в пределах одного сервера различные данные от разных источников. Согласен, что во все таблицы можно добавить ИД (филиала, источника и т.д.), наверно и секционирование по нему помогло бы. Но по каждому чиху на больших объемах юзать этот ИД, неужели ничего лучше нет?
Если речь не о реально разнесённых серверах филиалов/компаний, то бест-практик - делать одну базу.
Да, по каждому чиху юзать этот ИД.
Он на самом деле не "по каждому чиху" будет юзаться, а в очень небольшом проценте запросов, если подумать.
Типа "показать список менеджеров", но не "показать список заказов одного менеджера", и не "показать список менеджеров отдела №ннн".

Для заказов и деталей заказов вы же не запланируете создавать отдельную таблицу деталей для каждого заказа, что бы не "по каждому чиху на больших объемах юзать этот ИД"

Вполне нормальная практика.

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

Но нужно быть уверенным, что пересечений (общих оперативных данных) нет, что на практике бывает реже, чем кажется на первый взгляд - всё таки они филиалы, а не совсем сторонние фирмы.
Вот это и нужно исследовать в системе, что бы принять решение.
7 июл 15, 10:13    [17860659]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
alexeyvg
Если речь не о реально разнесённых серверах филиалов/компаний, то бест-практик - делать одну базу.
Да, по каждому чиху юзать этот ИД.
Он на самом деле не "по каждому чиху" будет юзаться, а в очень небольшом проценте запросов, если подумать.
Типа "показать список менеджеров", но не "показать список заказов одного менеджера", и не "показать список менеджеров отдела №ннн".

Для заказов и деталей заказов вы же не запланируете создавать отдельную таблицу деталей для каждого заказа, что бы не "по каждому чиху на больших объемах юзать этот ИД"

Вполне нормальная практика.

Абсолютно согласен. Думал это несколько по старинке, и думал схемы мне помогут реализовать подобное в одной БД без идентификатора "филиала".

alexeyvg, если все же разносить по базам, как лучше реализовать общее ядро справочников, причем редактируемое из любого "филиала". Только отдельной мастер-базой, плохо, что нет ссылочной целостности между базами. Делать в каждой БД такое ядро, как лучше тогда его синхронизировать между всеми БД. Триггерами после модификаций, накатывать изменения на все другие БД? Плохо, что нужно будет их все изменять при добавлении новой БД "нового филиала".
7 июл 15, 10:46    [17860796]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8839
Гость456
Владислав Колосов,

А какой тип репликации для справочников и для данных? Справочники peer to peer? А для данных филиалов транзакционная подписчик - центральный офис, а публикатор филиал? И что означает фильтрованные базы - артикли с предикатом?


Тип репликации выбирается исходя из соображений надежности доставки. Если сеть надежная, то репликация транзакций, если синхронизируется с какой-то периодичностью (неделя, месяц) или связь не надежная, то репликация слиянием (она требует супервизора для решения конфликтов).
7 июл 15, 11:19    [17861038]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8839
Гость123, добавить атрибут для разделения филиалов в нужные таблицы - вполне нормальное решение. Вместо секционирования Вы можете использовать фильтрованные индексы. Опять же, если ваш бизнес-сектор не потребует совместных отчетов по разным филиалам в произвольном сочетании.
7 июл 15, 11:21    [17861048]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Гость123
Guest
Владислав, я так понимаю фильтрованные индексы в 2008 появились. Чем они хороши? Если не трудно, чтоб как аргумент для перехода на 2008-ой.
7 июл 15, 15:12    [17862943]     Ответить | Цитировать Сообщить модератору
 Re: Ядро справочников, помогут ли схемы 2005  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8839
Гость123,

Я так понимаю, что Вас беспокоит то, что увеличится объем хранимых данных и время выборки. Фильтрованные индексы (как и секционирование) используются при поиске по значению, точно укладывающемуся в заданный интервал фильтра индекса.
Например, select id from dbo.table1 where id between 5 and 7. Если в базе есть индекс, который определяет значения ID от 3 до 10, то будет использован этот индекс. Соответственно, размер индекса будет меньше, чем по полной таблице, меньше количество чтений и быстрее поиск. Не всегда возможно секционировать данные по какому-то полю (или нецелесообразно, например, при поиске NOT NULL). В этом случае поможет фильтрованный индекс.
7 июл 15, 16:32    [17863367]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить