Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 одна БД VS много БД  [new]
fduch f.f.
Member

Откуда: Белокаменная
Сообщений: 260
работаю сейчас в проекте по разработке ERP системы состоящей из нескольких модулей
финансы, склад и т.п.
разработчики сделали отдельные БД для этих модулей
теперь получается что некоторые данные из одной БД используются в других БД

насколько допустимым является такой подход к проектированию?

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

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

может кто прояснит или даст ссылку ?
24 фев 16, 13:19    [18856938]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
_djХомяГ
Guest
fduch f.f.
еще читал что есть какие-то проблемы с транзакциями если в транзакции задействованы таблицы из разных БД
искал информацию на эту тему , но не нашел подробного описания как работают такие транзакции

Как то спорно :-))))
24 фев 16, 13:24    [18856971]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
fduch f.f.
работаю сейчас в проекте по разработке ERP системы состоящей из нескольких модулей
финансы, склад и т.п.
разработчики сделали отдельные БД для этих модулей
теперь получается что некоторые данные из одной БД используются в других БД

насколько допустимым является такой подход к проектированию?

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

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

может кто прояснит или даст ссылку ?


24 фев 16, 13:25    [18856986]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
fduch f.f.
Member

Откуда: Белокаменная
Сообщений: 260
_djХомяГ
fduch f.f.
еще читал что есть какие-то проблемы с транзакциями если в транзакции задействованы таблицы из разных БД
искал информацию на эту тему , но не нашел подробного описания как работают такие транзакции

Как то спорно :-))))


например у меня в одной БД явная транзакция которая обновляет данные в другой БД
что будет происходить в логах транзакций в этом случае?
24 фев 16, 13:27    [18856996]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
fduch f.f.
_djХомяГ
пропущено...

Как то спорно :-))))


например у меня в одной БД явная транзакция которая обновляет данные в другой БД
что будет происходить в логах транзакций в этом случае?


зачем такой зверинец с головняками?
пересмотрите модель
24 фев 16, 13:29    [18857012]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
fduch f.f.
Member

Откуда: Белокаменная
Сообщений: 260
Winnipuh
fduch f.f.
пропущено...


например у меня в одной БД явная транзакция которая обновляет данные в другой БД
что будет происходить в логах транзакций в этом случае?


зачем такой зверинец с головняками?
пересмотрите модель


разработчики говорят что им так удобнее разрабатывать
еще они при таком подходе имеют возможность разнести базы по разным серверам и связать их линкед серверами
24 фев 16, 13:31    [18857030]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
_djХомяГ
Guest
Знавал я системы в которых в разных базах существовали одноименные таблицы практически с одинаковой структурой в которых хранились разные сущности
24 фев 16, 13:36    [18857059]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
o-o
Guest
fduch f.f.
например у меня в одной БД явная транзакция которая обновляет данные в другой БД
что будет происходить в логах транзакций в этом случае?

ну и что будет-то?
в чьей базе изменения, в лог той базы и запишется.
а с временными таблицами вы работаете?
не смущает, что они все в темпдб живут, а не в вашей базе?
24 фев 16, 13:36    [18857065]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
fduch f.f.
Winnipuh
пропущено...


зачем такой зверинец с головняками?
пересмотрите модель


разработчики говорят что им так удобнее разрабатывать
еще они при таком подходе имеют возможность разнести базы по разным серверам и связать их линкед серверами


Передайте им, что придет злой Воронин и как следует надерёт им места, которыми они думали.

Сначала линкед сервера, потом распределенные транзакции.

Если уж в разных базах, то пусть через брокер общаются. Так, хоть за целостностью проследить можно.
24 фев 16, 13:46    [18857127]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
o-o
Guest
а модель у баз какая?
наверное, вы читали про синхронизацию восстановления на определенный момент времени.
когда половина даных там, а половина здесь, то да, засинхронизируйся при восстановлении
24 фев 16, 13:46    [18857132]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
o-o
Guest
вот это наверное:
Use Marked Transactions to Recover Related Databases Consistently (Full Recovery Model)
24 фев 16, 13:50    [18857168]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
fduch f.f.
Winnipuh
пропущено...


зачем такой зверинец с головняками?
пересмотрите модель


разработчики говорят что им так удобнее разрабатывать
еще они при таком подходе имеют возможность разнести базы по разным серверам и связать их линкед серверами


то, что им удобнее не значит, что это правильно.
имхую, что это неправильная идея с разносом и линкед серверами в даннмо случае.
Они еще не завершили, а вы уже видите недостатки
24 фев 16, 14:20    [18857399]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
fduch f.f.
Member

Откуда: Белокаменная
Сообщений: 260
Winnipuh
fduch f.f.
пропущено...


разработчики говорят что им так удобнее разрабатывать
еще они при таком подходе имеют возможность разнести базы по разным серверам и связать их линкед серверами


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



все инстансы в одной сети , в одном домене и даже физически расположены в одной серверной
как аргументировать что линкед серверы это плохо?
24 фев 16, 14:45    [18857577]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Speshuric
Member

Откуда: г. Москва
Сообщений: 129
fduch f.f.
работаю сейчас в проекте по разработке ERP системы состоящей из нескольких модулей
финансы, склад и т.п.
разработчики сделали отдельные БД для этих модулей
теперь получается что некоторые данные из одной БД используются в других БД

насколько допустимым является такой подход к проектированию?

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

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

может кто прояснит или даст ссылку ?


При любых действиях чувствительных к порядку транзакций могут возникнуть грабли. Это и восстановление БД из рез. копий, доставка журналов, CDC, Delayed Transaction Durability, AlwaysON, репликация и т. п. При строгом соблюдении разработчиками некоторых правил, это может не повлиять.
Есть очевидные вопросы к целостности при обслуживании одной из баз. Есть очевидные вопросы к тому, как организован доступ (логины, пользователи и т.п.) и как планируется внедрять эту ERP более чем на одном сервере. Очевидные вопросы, если настройки баз (напр. read committed snapshot) разные.
Всё решаемо, но вопрос целесообразности такой архитектуры - вопрос к архитектору системы. Для каких-то задач может быть и оправдано.

Связанные сервера в данном контексте (задействованы таблицы из разных БД) если и не "абсолютное зло", то близко к тому.
24 фев 16, 14:56    [18857660]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
fduch f.f.
Winnipuh
пропущено...


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



все инстансы в одной сети , в одном домене и даже физически расположены в одной серверной
как аргументировать что линкед серверы это плохо?


вы же сами пишете:
"вижу явные недостатки.. например нельзя создать внешние ключи, нельзя надежно синхронизировать бекапы

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

с этого и начните аргументировать
24 фев 16, 15:23    [18857858]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
slkfsk
Guest
fduch f.f.,

Linked server - это удаленный доступ к данным. Происходит он совсем не таким образом, как доступ к данным находящемся на локальном сервере. Это только Вам кажется, что у Вас один запрос при использовании linked server-ов. На самом деле у Вас 2 разных запроса на разных серверах. Результаты одного из запросов приходится копировать в адресное пространство другого сервера. Это довольно затратный процесс и с т.зрения ресурсов. Да и администрировать этот процесс дополнительно надо с т.зрения безопасности. У 99% моих клиентов через linked server-а можно получить доступ к таким данным, что они даже и не ожидают.
24 фев 16, 15:24    [18857861]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
rootman
Member

Откуда:
Сообщений: 114
Вопрос доступности всех баз одновременно. Вероятность того что поляжет одна из 10 баз что приведет к потере данных в лучшем случае, и возможно в позу зю встанет весь аппликейшен.
24 фев 16, 15:39    [18857928]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Голое рассуждение ни о чём :) Надо смотреть архитектуру, цели, доступность и. т.д.
PS
Вообще, практически всегда erp система работает с несколькими/многими источниками и никто не заставляет делать это на одном сервере/инстансе.
24 фев 16, 15:53    [18858003]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
zasandator
Member [скрыт] [заблокирован]

Откуда:
Сообщений: 4887
fduch f.f.,

Есть плюсы: например, нужно часть вынести в другое место, например на другой сервер, часть достаточно независимая. Ну пусть будет справочник КЛАДР, которым может пользоваться несколько систем...
Есть минусы: синхронизация, форин кеи понятно... Мне доставляло, например, когда на сервере было 3 базы для одной системы и много филиалов (в частности 80), то что бы поднять 2-3 филиала на тесте, требовалось 2-3 инстанса СКЛ, а было бы в одной базе, коннекшн стринг с базой филиала указал, и на одном инстансе хоть все 80 филиалов поднимай... А так в коде встречается select * from db1.dbo.tbl1, db2.dbo.tbl2 ... и собственно имена баз неизменны должны быть из-за такого кода.
24 фев 16, 22:06    [18859750]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
fduch f.f.
разработчики говорят что им так удобнее разрабатывать
еще они при таком подходе имеют возможность разнести базы по разным серверам и связать их линкед серверами
Это для того чтобы если криво написанный код начнет тормозить, то можно было производительность увеличить за счет масштабирования?

Тогда уж пусть берут полностью distributed database, например Azure DocumentDB или MongoDB и там развлекаются, зачем им SQL Server?
25 фев 16, 01:16    [18860101]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
постоянный мембер
Guest
Мой пример буквально на днях:

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

Подобных действий (с ф-циями), но в одной БД - многие десятки и работают на ура.

по сабжу: Идея с кучей баз - тупиковая.
25 фев 16, 10:39    [18860855]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1734
fduch f.f.,

А про разные схемы базы Ваши "разработчики" когда-нибудь слышали?
25 фев 16, 12:59    [18861824]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Если заказчик ведется на то, что удобно девелоперам это п-ц прожекту (ц, моё)
25 фев 16, 13:13    [18861917]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
Winnipuh
Если заказчик ведется на то, что удобно девелоперам это п-ц прожекту (ц, моё)

Когда заказчик лезет в проектирование, получается еще хуже.
25 фев 16, 13:22    [18861969]     Ответить | Цитировать Сообщить модератору
 Re: одна БД VS много БД  [new]
MSSQLAndDotNet
Member

Откуда:
Сообщений: 10398
fduch f.f.,

в Шарепоинте сделано так

это удобно, если Вы проектируете систему в которой можно будет включать/отключать разные тяжелые службы/сервисы
и каждая из которых пусть живет своей жизнью и по минимуму затрагивает другие
25 фев 16, 14:35    [18862423]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить