LINUX.ORG.RU

Базы данных: зачем может понадобится разносить таблицы по разным базам данных?

 ,


0

1

Всем привет.

Разбираюсь в устройстве одной системы. Упрощая, она состоит из двух инстансов: Processing Node и Console. Данные хранятся в базах данных - в двух; назовём их db1 и db2. Processing Node ипользует данные только из db1, а Console - из db1 и db2.

Теперь вопрос: зачем могло понадобиться разносить таблицы по двум разным базам данных?

Спасибо.

★★★★★

Теперь вопрос: зачем могло понадобиться разносить таблицы по двум разным базам данных?

Например, вторая база в будущем должна находиться на удаленной машине, и архитектура приложения уже под это заточена, осталось только переключить режим для работы с удаленной базой. А если ты спросишь – почему нельзя было _все_ сделать изначально в одной базе – вопрос к проектировщикам. Вдруг обе базы с чисто мнения проектировщика являются независимыми друг от друга.

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

Например, вторая база в будущем должна находиться на удаленной машине

Может так: при разрастании баз данных можно их отдельно скейлить?

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

Ну, определенные связи между ними есть. Я не шибко разбираюсь в базах данных, и был удивлён, когда не смог сделать join. Потому и спрашиваю.

Kroz ★★★★★
() автор топика
Ответ на: комментарий от pi11

Скорее всего историческое наследие.

В смысле? Кто-то изначально накосячил?

db2 - ее схема была разработана лет 10 назад, а схема для db1 - пару лет назад в связи с добавлением нового функционала.

Kroz ★★★★★
() автор топика
Ответ на: комментарий от Kroz

Я не шибко разбираюсь в базах данных, и был удивлён, когда не смог сделать join

Ну все зависит от задачи. Возьмем гипотетический случай. Твоя база db1 – это, скажем, обычная база простого сайта. Пусть туда приходят заявки с него. Теперь представим, что у тебя большие масштабы и ты делаешь для всех регионов глобальную базу заявок, это будет db2. И твой сайт N региона A должен при добавлении заявки к себе, дублировать ее с доп. данными к удаленной базе db2. Потом уже какие-нибудь манагеры, через какую-нибудь web-морду, как-то там работают с ней, это уже не важно. Вот если примерно так разделены базы, и _пока_ на какой-то отдельной стадии db2 просто хранится на текущем сервере, то это еще можно понять. А вот если у тебя в db1 тупо каталог какой-нибудь, и, допустим, в db2 есть таблицы которые чисто логически должны быть в db1 – то это уже маразм. Короче – все зависит от ситуации. Входных данных слишком мало чтобы говорить «что это» или обсирать кого-то конкретного.

znenyegvkby
()
Последнее исправление: znenyegvkby (всего исправлений: 1)
Ответ на: комментарий от Kroz

db2 - ее схема была разработана лет 10 назад, а схема для db1 - пару лет назад в связи с добавлением нового функционала.

дык ты сам ответил на свой вопрос

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.