Разделение данных на несколько баз данных

[segreb]

Подскажите, есть ли смысл разделять данные приложения на несколько баз данных. Используемые таблицы можно условно разделить на три группы:
1. Справочники. Обновляются очень редко и только ограниченным кругом пользователей. Около десяти таблиц.
2. Картотека клиентов. Таблицы пополняются несколько раз в день. Примерно 20 таблиц.
3. Операции с клиентами. Частота пополнений-обновлений - несколько раз в час. Примерно 20 таблиц.
Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.
Будет ли хоть какая-то польза, если разнести эти группы таблиц в разные базы? Гипотетический плюс - если выйдет из строя одна из баз, это не затронет остальные. Явный минус - клиентскому приложению надо держать три соединения вместо одного.
А какие ещё соображения?

[kdv]

Явный минус - клиентскому приложению надо держать три соединения вместо одного

незачет:
1. ссылочную целостность невозможно поддержать между базами
2. гетерогенные запросы поддерживаются только BDE, на стороне клиента
3. если выйдет из строя одна из баз, например не-справочная, то каков будет смысл существования остальных баз???
4. предполагая что "выйдет из строя одна из баз"
а) не предполагается базам делать резервных копий?
б) предполагается, что оставшиеся базы все-таки могут работать автономно?

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

встречный вопрос - что Вы хотите сэкономить? Вам страшно, что в базе будет аж 50 таблиц? Есть базы по 3-4 сотни таблиц, и ничего.
Ваша база будет размером в десятки и сотни гигабайт? сомневаюсь.

Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.

какой-то странный аргумент, если это вообще аргумент. Таких транзакций по идее и быть-то не должно.

Так что, до минуса в виде трех соединений из приложения тут очень далеко.

А какие ещё соображения?

копите опыт проектирования БД.

[WildSery]

Есть базы по 3-4 сотни таблиц, и ничего.

Дим, это ты про известные в FB или вообще?
Я просто вспомнил, недавно кто-то (как бы не ты) упоминал, что в полном пакете SAP сейчас около 40000 таблиц.

[kdv]

это ты про известные в FB или вообще?

гм, а что тут такого-то, 300 таблиц? "известные"...
вон, у меня на диске валяются базы (чужие), 5-6 летней давности-
89 таблиц
161 таблица
367 таблиц
333 таблицы
284 таблицы

еще раз подчеркиваю - это базы 5-6 летней давности.

[Merlin]

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

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

[WildSery]

Ой, а я, а у меня!

Наразводил таблиц, понимаешь
А вот моя ... :

Код: Выделить всё

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]

база полегчала до смешного

я про вас специально промолчал, т.к. в последний раз помнил что таблиц было не то 500 не то 700.

триггеров, кстати, 1800 - нормально. Даже в базах с 300 таблиц их тоже часто бывает под 1500.

[segreb]

Явный минус - клиентскому приложению надо держать три соединения вместо одного

незачет:
1. ссылочную целостность невозможно поддержать между базами

Относительно ссылочной целостности я выбрал такой подход. Если база, на таблицы которой есть ссылки, находится в неактуальном состоянии, то я могу просигналить оператору "там что-то есть, но что именно - сейчас показать не можем, ждите окончания регламентных работ". В таком духе.

2. гетерогенные запросы поддерживаются только BDE, на стороне клиента

Боюсь, не понял. Разрабатываю на Delphi, без BDE, использую FibPlus. Запросов, выбирающих одновременно из таблиц разных баз, нет.

3. если выйдет из строя одна из баз, например не-справочная, то каков будет смысл существования остальных баз???
4. предполагая что "выйдет из строя одна из баз"
а) не предполагается базам делать резервных копий?
б) предполагается, что оставшиеся базы все-таки могут работать автономно?

Идея была такая. В приложении, в любой момент времени, для выполнения текущей работы, нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа, и не спеша поднимать данные. И никто этого не заметит, кроме нескольких операторов.
Полной независимости клиентов от операций нет, но гораздо легче востановить одну базу, если вторая в актуальном состоянии.

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

встречный вопрос - что Вы хотите сэкономить? Вам страшно, что в базе будет аж 50 таблиц? Есть базы по 3-4 сотни таблиц, и ничего.
Ваша база будет размером в десятки и сотни гигабайт? сомневаюсь.

Ну, интересует типовое решение. Я сейчас нахожусь под влиянием шаблонов проектирования и разработки. Что могу - разделяю и концентрирую

Транзакций, которые изменяют данные одновременно в разных группах таблиц, нет.

какой-то странный аргумент, если это вообще аргумент. Таких транзакций по идее и быть-то не должно.

Да, коряво сказал. Имел в виду, что двух-, трёх- и много-фазных транзакций не понадобится.

Так что, до минуса в виде трех соединений из приложения тут очень далеко.

А какие ещё соображения?

копите опыт проектирования БД.

[kdv]

Запросов, выбирающих одновременно из таблиц разных баз, нет.

если у вас справочники в одной БД, а оперативная информация - в другой, как вы собираетесь показывать эту информацию в приложении?
по очереди выбирая инфу из двух баз? А если надо, допустим, показать какие операции кто делал с клиентом?
например, www.ibase.ru/devinfo/joins.htm

Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.

Ну, интересует типовое решение.

общее типовое решение - в СУБД так обычно никто не "разделяет", я имею в виду на разные БД.

нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа

бэкапы предполагаете делать каждый час? откуда будете брать "историю" за последний час?

но гораздо легче востановить одну базу, если вторая в актуальном состоянии.

то есть, если повредился справочник, остальное у нас целое? А если все в одной БД, и повредился справочник, то ... Собственно, тогда все равно можно "подложить версию из бэкапа" и использовать историю операций.

А хранить это предполагается как? Т.е. вот три базы будут где именно, чтобы минимизировать повреждение их всех или по отдельности? И что предполагается под "повреждением"?

[Merlin]

Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.

Тяжкое наследие режима (С). То есть - файл-серверных баз и даже record manager-ов. SQL - работа с множествами. Пересечения там, объединения и всё такое. Попытки притянуть его за уши к привычной позаписной работе и циклам обречены на катастрофическое снижение производительности и несусветный гимор при выполнении примитивнейших рутинных действий. И, что характерно, никакой дополнительной надёжности это не даёт, даже напротив. Если справочники условно-постоянны, то какая нахрен разница, из которого бакапа они подняты. А оперативка если утеряна, то по-любому утеряна. Тем более есть варианты извлечения чего можно из повреждённых баз.

[Ivan_Pisarevsky]

Подскажите, есть ли смысл разделять данные приложения на несколько баз данных. Используемые таблицы можно условно разделить на три группы:
SKIP
А какие ещё соображения?

Бред. Делить смысла нет. Как перевалит гигов за 100, приходи, тогда подумаем как делить, вдоль или поперек.

[belov-evgenii]

Как перевалит гигов за 100, приходи, тогда подумаем как делить, вдоль или поперек.

Когда у него перевалит за 100 гигов, лет наверно дцать пройдет. И железо будет другое

[avenger]

А чем плохо, например, КЛАДР вынести в отдельную базу?

У меня например на данный момент ТОЛЬКО КЛАДР лежит в отдельной ReadOnly базе. А в информационных базах - ID объекта и реальный адрес объекта.

[segreb]

Запросов, выбирающих одновременно из таблиц разных баз, нет.

если у вас справочники в одной БД, а оперативная информация - в другой, как вы собираетесь показывать эту информацию в приложении?
по очереди выбирая инфу из двух баз? А если надо, допустим, показать какие операции кто делал с клиентом?
например, www.ibase.ru/devinfo/joins.htm

Ваше непонимание этого вопроса навевает странные мысли по поводу проектируемой БД.

Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.

Ну, интересует типовое решение.

общее типовое решение - в СУБД так обычно никто не "разделяет", я имею в виду на разные БД.

Угу. Ясно.

нужна история операций не более чем за последний час. Таким образом, если падает одна база, можно подложить на её место версию из бакапа

бэкапы предполагаете делать каждый час? откуда будете брать "историю" за последний час?

Нет, бакапы делаются раз в день, после работы. Насчёт истории последнего часа - долго расписывать, но есть способы восстановить данные "по горячим следам".

но гораздо легче востановить одну базу, если вторая в актуальном состоянии.

то есть, если повредился справочник, остальное у нас целое? А если все в одной БД, и повредился справочник, то ... Собственно, тогда все равно можно "подложить версию из бэкапа" и использовать историю операций.

Извиняюсь за неясности. Тут я имел в виду базы с оперативной информацией - клиенты и операции с ними. Если упала база клиентов, то делается восстановление из вечернего бакапа, а данные клиентов восстанавливаются по операциям. Есть способы соотнести операции за номерами, например, X, Y и Z с определённым клиентом и "вспомнить" его данные. Соответственно, добавляем клиента в базу клиентов, привязываем к нему его операции и т.д.
Если упала база операций, то ещё проще. Опять же восстановление из бакапа. Оператор помнит, что он делал определённому клиенту и просто восстанавливает операции.
А вот если исчезли и клиенты, и операции, то восстановление информации затрудняется в разы.

А хранить это предполагается как? Т.е. вот три базы будут где именно, чтобы минимизировать повреждение их всех или по отдельности? И что предполагается под "повреждением"?

Мысль хорошая, но сервер всё-таки один Ну, может быть, разные базы - на разных разделах диска.
Сравнительно недавно наблюдал сообщение от Firebird 2.01: "Неправильный дескриптор страницы" или что-то в этом роде. Причём ничего крамольного с базой не делалось - выполнял такие же операции, что и десятки раз до этого. Хорошо, что IBSurgeon (?, не ручаюсь что это был именно он) исправил структуру базы, и вроде обошлось без потерь. А если бы не исправил? Тогда из-за _одной_ битой страницы (на которой возможно, расположены пара записей из неизменяемого справочника), я не имею доступа ко _всей_ базе. Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.
Впрочем, если уважаемое сообщество скажет, что это не та причина, из-за которой стоит заморачиваться с несколькими базами, то я и не буду.

[kdv]

Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.

мда, Merlin был прав - тяжелое наследие файл-сервера.

Мысль хорошая, но сервер всё-таки один Smile Ну, может быть, разные базы - на разных разделах диска.

тогда вся эта идея - просто от нечего делать.

Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.

а бэкап? где же волшебный бэкап, про который тут было так чудесно расписано?

p.s. IBSurgeon - это название компании. Которая выпускает разные инструменты для IB/FB.

[segreb]

Join'ов со справочниками не предвидится. Там, где нужен был бы join, можно обойтись использованием lookup-полей.

мда, Merlin был прав - тяжелое наследие файл-сервера.

Люди, я не знаю, на чём вы с Merlin'ом пишете, но приложения давно уже не разрабатываются на чисто SQL'е.

Мысль хорошая, но сервер всё-таки один Smile Ну, может быть, разные базы - на разных разделах диска.

тогда вся эта идея - просто от нечего делать.

Вся эта идея - от попытки узнать как сделать лучше.

Или из-за _одной_ битой страницы с третьестепенной информацией, которой сейчас можно и пожертвовать, я не имею доступ ко _всей_ базе. Вот от таких сюрпризов я и хотел подстраховаться.

а бэкап? где же волшебный бэкап, про который тут было так чудесно расписано?

Бекап лежит на специальном компе и ждёт пока им воспользуются. Я же написал - "А если бы не исправил?". Вот тогда из-за битой страницы я теряю доступ к базе.

p.s. IBSurgeon - это название компании. Которая выпускает разные инструменты для IB/FB.

[kdv]

Люди, я не знаю, на чём вы с Merlin'ом пишете, но приложения давно уже не разрабатываются на чисто SQL'е.

где-то в 1998 году, знакомый передал фразу - "если ты не умеешь пользоваться JOIN, значит, не знаешь SQL".

Поскольку Вы изъявили желание покинуть форум по непонятным причинам - в добрый путь. Захотите поговорить о производительности создаваемых Вами приложений (с лукапами) - возвращайтесь.

[Ivan_Pisarevsky]

Забавно у вас тут... улыбнуло, особенно проникновенно это:
"Если упала база клиентов, то делается восстановление из вечернего бакапа, а данные клиентов восстанавливаются по операциям. Есть способы соотнести операции за номерами, например, X, Y и Z с определённым клиентом и "вспомнить" его данные. Соответственно, добавляем клиента в базу клиентов, привязываем к нему его операции и т.д.
Если упала база операций, то ещё проще. Опять же восстановление из бакапа. Оператор помнит, что он делал определённому клиенту и просто восстанавливает операции.
А вот если исчезли и клиенты, и операции, то восстановление информации затрудняется в разы."

Поржал вобщем.

А чем плохо, например, КЛАДР вынести в отдельную базу?

У меня например на данный момент ТОЛЬКО КЛАДР лежит в отдельной ReadOnly базе. А в информационных базах - ID объекта и реальный адрес объекта.

Что мешает дать гранты только на чтение? кладр с точки зрения мировой революции копейки весит, на кой его окучивать отдельно? Ликвидация безработицы? Баловство.