Разделение данных на несколько баз данных
Разделение данных на несколько баз данных
Подскажите, есть ли смысл разделять данные приложения на несколько баз данных. Используемые таблицы можно условно разделить на три группы:
1. Справочники. Обновляются очень редко и только ограниченным кругом пользователей. Около десяти таблиц.
2. Картотека клиентов. Таблицы пополняются несколько раз в день. Примерно 20 таблиц.
3. Операции с клиентами. Частота пополнений-обновлений - несколько раз в час. Примерно 20 таблиц.
Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.
Будет ли хоть какая-то польза, если разнести эти группы таблиц в разные базы? Гипотетический плюс - если выйдет из строя одна из баз, это не затронет остальные. Явный минус - клиентскому приложению надо держать три соединения вместо одного.
А какие ещё соображения?
1. Справочники. Обновляются очень редко и только ограниченным кругом пользователей. Около десяти таблиц.
2. Картотека клиентов. Таблицы пополняются несколько раз в день. Примерно 20 таблиц.
3. Операции с клиентами. Частота пополнений-обновлений - несколько раз в час. Примерно 20 таблиц.
Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.
Будет ли хоть какая-то польза, если разнести эти группы таблиц в разные базы? Гипотетический плюс - если выйдет из строя одна из баз, это не затронет остальные. Явный минус - клиентскому приложению надо держать три соединения вместо одного.
А какие ещё соображения?
незачет:Явный минус - клиентскому приложению надо держать три соединения вместо одного
1. ссылочную целостность невозможно поддержать между базами
2. гетерогенные запросы поддерживаются только BDE, на стороне клиента
3. если выйдет из строя одна из баз, например не-справочная, то каков будет смысл существования остальных баз???
4. предполагая что "выйдет из строя одна из баз"
а) не предполагается базам делать резервных копий?
б) предполагается, что оставшиеся базы все-таки могут работать автономно?
встречный вопрос - что Вы хотите сэкономить? Вам страшно, что в базе будет аж 50 таблиц? Есть базы по 3-4 сотни таблиц, и ничего.Будет ли хоть какая-то польза, если разнести эти группы таблиц в разные базы?
Ваша база будет размером в десятки и сотни гигабайт? сомневаюсь.
какой-то странный аргумент, если это вообще аргумент. Таких транзакций по идее и быть-то не должно.Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.
Так что, до минуса в виде трех соединений из приложения тут очень далеко.
копите опыт проектирования БД.А какие ещё соображения?
Ой, а я, а у меня! Я тут как раз вычищал атавизьмы и рудименты, база полегчала до смешного:
select count(*) from rdb$relations
COUNT
===========
968
select count(*) from rdb$triggers
COUNT
===========
1864
select count(*) from rdb$procedures
COUNT
===========
1503
select count(*) from rdb$indices
COUNT
===========
3236
select count(*) from rdb$relations
COUNT
===========
968
select count(*) from rdb$triggers
COUNT
===========
1864
select count(*) from rdb$procedures
COUNT
===========
1503
select count(*) from rdb$indices
COUNT
===========
3236
Наразводил таблиц, понимаешьMerlin писал(а):Ой, а я, а у меня!
А вот моя ... :
Код: Выделить всё
select 'relations' obj, count(*) cnt from rdb$relations
union all
select 'triggers', count(*) from rdb$triggers
union all
select 'procedures', count(*) from rdb$procedures
union all
select 'indices', count(*) from rdb$indices;
OBJ CNT
========== ============
relations 166
triggers 377
procedures 2504
indices 374
Относительно ссылочной целостности я выбрал такой подход. Если база, на таблицы которой есть ссылки, находится в неактуальном состоянии, то я могу просигналить оператору "там что-то есть, но что именно - сейчас показать не можем, ждите окончания регламентных работ". В таком духе.kdv писал(а):незачет:Явный минус - клиентскому приложению надо держать три соединения вместо одного
1. ссылочную целостность невозможно поддержать между базами
Боюсь, не понял. Разрабатываю на Delphi, без BDE, использую FibPlus. Запросов, выбирающих одновременно из таблиц разных баз, нет.kdv писал(а):2. гетерогенные запросы поддерживаются только BDE, на стороне клиента
Идея была такая. В приложении, в любой момент времени, для выполнения текущей работы, нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа, и не спеша поднимать данные. И никто этого не заметит, кроме нескольких операторов.kdv писал(а):3. если выйдет из строя одна из баз, например не-справочная, то каков будет смысл существования остальных баз???
4. предполагая что "выйдет из строя одна из баз"
а) не предполагается базам делать резервных копий?
б) предполагается, что оставшиеся базы все-таки могут работать автономно?
Полной независимости клиентов от операций нет, но гораздо легче востановить одну базу, если вторая в актуальном состоянии.
Ну, интересует типовое решение. Я сейчас нахожусь под влиянием шаблонов проектирования и разработки. Что могу - разделяю и концентрируюkdv писал(а):встречный вопрос - что Вы хотите сэкономить? Вам страшно, что в базе будет аж 50 таблиц? Есть базы по 3-4 сотни таблиц, и ничего.Будет ли хоть какая-то польза, если разнести эти группы таблиц в разные базы?
Ваша база будет размером в десятки и сотни гигабайт? сомневаюсь.
Да, коряво сказал. Имел в виду, что двух-, трёх- и много-фазных транзакций не понадобится.kdv писал(а):какой-то странный аргумент, если это вообще аргумент. Таких транзакций по идее и быть-то не должно.Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.
kdv писал(а): Так что, до минуса в виде трех соединений из приложения тут очень далеко.
копите опыт проектирования БД.А какие ещё соображения?
если у вас справочники в одной БД, а оперативная информация - в другой, как вы собираетесь показывать эту информацию в приложении?Запросов, выбирающих одновременно из таблиц разных баз, нет.
по очереди выбирая инфу из двух баз? А если надо, допустим, показать какие операции кто делал с клиентом?
например, www.ibase.ru/devinfo/joins.htm
Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.
общее типовое решение - в СУБД так обычно никто не "разделяет", я имею в виду на разные БД.Ну, интересует типовое решение.
бэкапы предполагаете делать каждый час? откуда будете брать "историю" за последний час?нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа
то есть, если повредился справочник, остальное у нас целое? А если все в одной БД, и повредился справочник, то ... Собственно, тогда все равно можно "подложить версию из бэкапа" и использовать историю операций.но гораздо легче востановить одну базу, если вторая в актуальном состоянии.
А хранить это предполагается как? Т.е. вот три базы будут где именно, чтобы минимизировать повреждение их всех или по отдельности? И что предполагается под "повреждением"?
Тяжкое наследие режима (С). То есть - файл-серверных баз и даже record manager-ов. SQL - работа с множествами. Пересечения там, объединения и всё такое. Попытки притянуть его за уши к привычной позаписной работе и циклам обречены на катастрофическое снижение производительности и несусветный гимор при выполнении примитивнейших рутинных действий. И, что характерно, никакой дополнительной надёжности это не даёт, даже напротив. Если справочники условно-постоянны, то какая нахрен разница, из которого бакапа они подняты. А оперативка если утеряна, то по-любому утеряна. Тем более есть варианты извлечения чего можно из повреждённых баз.kdv писал(а): Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Re: Разделение данных на несколько баз данных
Бред. Делить смысла нет. Как перевалит гигов за 100, приходи, тогда подумаем как делить, вдоль или поперек.segreb писал(а):Подскажите, есть ли смысл разделять данные приложения на несколько баз данных. Используемые таблицы можно условно разделить на три группы:
SKIP
А какие ещё соображения?
-
- Сообщения: 52
- Зарегистрирован: 28 сен 2007, 10:19
Re: Разделение данных на несколько баз данных
Когда у него перевалит за 100 гигов, лет наверно дцать пройдет. И железо будет другоеIvan_Pisarevsky писал(а):Как перевалит гигов за 100, приходи, тогда подумаем как делить, вдоль или поперек.
Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.kdv писал(а):если у вас справочники в одной БД, а оперативная информация - в другой, как вы собираетесь показывать эту информацию в приложении?Запросов, выбирающих одновременно из таблиц разных баз, нет.
по очереди выбирая инфу из двух баз? А если надо, допустим, показать какие операции кто делал с клиентом?
например, www.ibase.ru/devinfo/joins.htm
Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.
Угу. Ясно.kdv писал(а):общее типовое решение - в СУБД так обычно никто не "разделяет", я имею в виду на разные БД.Ну, интересует типовое решение.
Нет, бакапы делаются раз в день, после работы. Насчёт истории последнего часа - долго расписывать, но есть способы восстановить данные "по горячим следам".kdv писал(а):бэкапы предполагаете делать каждый час? откуда будете брать "историю" за последний час?нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа
Извиняюсь за неясности. Тут я имел в виду базы с оперативной информацией - клиенты и операции с ними. Если упала база клиентов, то делается восстановление из вечернего бакапа, а данные клиентов восстанавливаются по операциям. Есть способы соотнести операции за номерами, например, X, Y и Z с определённым клиентом и "вспомнить" его данные. Соответственно, добавляем клиента в базу клиентов, привязываем к нему его операции и т.д.kdv писал(а):то есть, если повредился справочник, остальное у нас целое? А если все в одной БД, и повредился справочник, то ... Собственно, тогда все равно можно "подложить версию из бэкапа" и использовать историю операций.но гораздо легче востановить одну базу, если вторая в актуальном состоянии.
Если упала база операций, то ещё проще. Опять же восстановление из бакапа. Оператор помнит, что он делал определённому клиенту и просто восстанавливает операции.
А вот если исчезли и клиенты, и операции, то восстановление информации затрудняется в разы.
Мысль хорошая, но сервер всё-таки один Ну, может быть, разные базы - на разных разделах диска.kdv писал(а):А хранить это предполагается как? Т.е. вот три базы будут где именно, чтобы минимизировать повреждение их всех или по отдельности? И что предполагается под "повреждением"?
Сравнительно недавно наблюдал сообщение от Firebird 2.01: "Неправильный дескриптор страницы" или что-то в этом роде. Причём ничего крамольного с базой не делалось - выполнял такие же операции, что и десятки раз до этого. Хорошо, что IBSurgeon (?, не ручаюсь что это был именно он) исправил структуру базы, и вроде обошлось без потерь. А если бы не исправил? Тогда из-за _одной_ битой страницы (на которой возможно, расположены пара записей из неизменяемого справочника), я не имею доступа ко _всей_ базе. Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.
Впрочем, если уважаемое сообщество скажет, что это не та причина, из-за которой стоит заморачиваться с несколькими базами, то я и не буду.
мда, Merlin был прав - тяжелое наследие файл-сервера.Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.
тогда вся эта идея - просто от нечего делать.Мысль хорошая, но сервер всё-таки один Smile Ну, может быть, разные базы - на разных разделах диска.
а бэкап? где же волшебный бэкап, про который тут было так чудесно расписано?Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.
p.s. IBSurgeon - это название компании. Которая выпускает разные инструменты для IB/FB.
Люди, я не знаю, на чём вы с Merlin'ом пишете, но приложения давно уже не разрабатываются на чисто SQL'е.kdv писал(а):мда, Merlin был прав - тяжелое наследие файл-сервера.Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.
Вся эта идея - от попытки узнать как сделать лучше.kdv писал(а):тогда вся эта идея - просто от нечего делать.Мысль хорошая, но сервер всё-таки один Smile Ну, может быть, разные базы - на разных разделах диска.
Бекап лежит на специальном компе и ждёт пока им воспользуются. Я же написал - "А если бы не исправил?". Вот тогда из-за битой страницы я теряю доступ к базе.kdv писал(а):а бэкап? где же волшебный бэкап, про который тут было так чудесно расписано?Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.
kdv писал(а): p.s. IBSurgeon - это название компании. Которая выпускает разные инструменты для IB/FB.
где-то в 1998 году, знакомый передал фразу - "если ты не умеешь пользоваться JOIN, значит, не знаешь SQL".Люди, я не знаю, на чём вы с Merlin'ом пишете, но приложения давно уже не разрабатываются на чисто SQL'е.
Поскольку Вы изъявили желание покинуть форум по непонятным причинам - в добрый путь. Захотите поговорить о производительности создаваемых Вами приложений (с лукапами) - возвращайтесь.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Забавно у вас тут... улыбнуло, особенно проникновенно это:
"Если упала база клиентов, то делается восстановление из вечернего бакапа, а данные клиентов восстанавливаются по операциям. Есть способы соотнести операции за номерами, например, X, Y и Z с определённым клиентом и "вспомнить" его данные. Соответственно, добавляем клиента в базу клиентов, привязываем к нему его операции и т.д.
Если упала база операций, то ещё проще. Опять же восстановление из бакапа. Оператор помнит, что он делал определённому клиенту и просто восстанавливает операции.
А вот если исчезли и клиенты, и операции, то восстановление информации затрудняется в разы."
Поржал вобщем.
"Если упала база клиентов, то делается восстановление из вечернего бакапа, а данные клиентов восстанавливаются по операциям. Есть способы соотнести операции за номерами, например, X, Y и Z с определённым клиентом и "вспомнить" его данные. Соответственно, добавляем клиента в базу клиентов, привязываем к нему его операции и т.д.
Если упала база операций, то ещё проще. Опять же восстановление из бакапа. Оператор помнит, что он делал определённому клиенту и просто восстанавливает операции.
А вот если исчезли и клиенты, и операции, то восстановление информации затрудняется в разы."
Поржал вобщем.
Что мешает дать гранты только на чтение? кладр с точки зрения мировой революции копейки весит, на кой его окучивать отдельно? Ликвидация безработицы? Баловство.А чем плохо, например, КЛАДР вынести в отдельную базу?
У меня например на данный момент ТОЛЬКО КЛАДР лежит в отдельной ReadOnly базе. А в информационных базах - ID объекта и реальный адрес объекта.