Список БД в InterBase/FireBird

← →
Адмирал © (2004-05-13 07:44) [0]

Есть сервер БД, на нем несколько многопользовательских баз.
Я так понял, что InterBase нигде не хранит информацию о расположении БД.
Подскажите, как лучше организовать и вести список БД, который будет выдавать пользователю приложение, чтобы он мог выбирать, с какой базой работать.
Вести какой-то конфигурационный файл на каждой пользовательской машине как-то не то...
Жестко создать отдельную БД с таблицей всех баз и централизованно вести ее? Тоже как-то... Каждый раз при добавлении нового пользователя надо прописывать ему права на чтение этой таблицы...

Наверняка, есть более красивое решение.
Буду благодарен мэтрам за помощь.

← →
y-soft © (2004-05-13 08:47) [1]

Типового решения не существует.

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

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

А можно ничего и не городить, а заставить администратора БД честно отрабатывать свой хлеб :)

← →
Sergey13 © (2004-05-13 09:15) [2]

2Адмирал © (13.05.04 07:44)
Просто интересно, а зачем такое надо? Такой "список" был бы полезен, если работать IBExpert-ом каким нить. Если же есть конкретная приклада (склад какой нить), то наверное ей нужна конкретная база. Если все базы одинаковы, то нафига их много?

Любопыто мне просто.

← →
y-soft © (2004-05-13 09:23) [3]

>Sergey13 © (13.05.04 09:15) [2]

Задачи такие есть. Например, сервер по факту необслуживаемый, или пользователей много и часто меняются, или состав рабочих баз непостоянен и их много (у нас в одном проекте всё именно так)

IB используется не только для ведения бухгалтерии|склада :)

← →
Sergey13 © (2004-05-13 09:37) [4]

2y-soft © (13.05.04 09:23) [3]
>Задачи такие есть.
Вот мне и интересно - какие? Правда интересно.

>сервер по факту необслуживаемый,
Это как?

>или пользователей много и часто меняются,
Ну и что. Каждому юзеру по базе?

>или состав рабочих баз непостоянен и их много
Не понял. В понедельник с одной базой, во вторник с другой работать.

>IB используется не только для ведения бухгалтерии|склада :)
Вот спасибо, а я думал ИБ и склад близнецы-братья. 8-)

ЗЫ: Это не наезд или еще чего. Просто любопытство.

← →
Соловьев © (2004-05-13 09:44) [5]

ИМХО, перейди на ФБ 1.5 - там нет привязки к файлам - создай алиас и все. Пользователь даже не будет знать с какой он БД работает. Если конечно эти БД одинаковой структуры или он работает через ява-аплет?

← →
Адмирал © (2004-05-13 10:01) [6]

Несколько баз одинаковой структуры... каждая хранит информацию об определенном тренажерном комплексе, на основании этой информации строятся исходники и файлы для работы ядра общего мат. обеспечения комплекса. Естественно, приложение одно (БД одинаковые), а доступ к конкретным базам должны иметь только те, кто должен.) Иногда разработчик занимается несколькими комплексами. Вот и...)

Решения понятны, спасибо большое...

Только интересно про FB 1.5. Можно чуть подробнее?
Как там создаются алиасы?
SQL-командами или средствами каких-то консолей?
И как их потом использовать в приложении? В качестве имени БД?
Опять же... как получить список всех алиасов?

← →
Соловьев © (2004-05-13 10:06) [7]

> доступ к конкретным базам должны иметь только те, кто должен.)
>

ИМХО, у тебя со структурой БД наворочено... Нафиг несколько БД? Создай одну и там разграничь и права и данные...

А про алиасы. Там создаются админом БД - в текстовом файле. На сервере. А в клиентском приложении указывают вместо пути к БД имя алиаса.

← →
Адмирал © (2004-05-13 10:21) [8]

>А про алиасы. Там создаются админом БД - в текстовом файле. На сервере. А в клиентском приложении указывают вместо пути к БД имя алиаса.

Спасибо!

← →
y-soft © (2004-05-13 10:21) [9]

>Sergey13 © (13.05.04 09:37) [4]

Раз это не наезд, то отвечаю по пунктам :)

Вот мне и интересно - какие? Правда интересно.

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

>сервер по факту необслуживаемый,
Это как?

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

>или пользователей много и часто меняются,

См. предыдущий пункт :( Регистрация пользователей и назначение им прав осуществляется не администратором БД, а начальником службы через спец. компонент приложения. При этом начальник и знать не знает ничего о каких-то там БД

Не понял. В понедельник с одной базой, во вторник с другой работать.

Да, примерно так.

Во-первых - могут быть обособленные базы для разных районов.

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

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

← →
Sergey13 © (2004-05-13 10:40) [10]

2y-soft © (13.05.04 10:21) [9]
Спасибо за разъяснения.

>Это, например, автоматизированные системы управления дорожным движением в масштабах больших городов...
Не очень понятно, но пусть будет так. 8-)

>А так и есть - даже в городах-милионниках в таких службах просто нет ставки для администратора БД.
Значит, если много одинаковых баз, то админ не нужен. Если одна большая - нужен. Что то сумнительно больно.

>Регистрация пользователей и назначение им прав осуществляется не администратором БД, а начальником службы через спец. компонент приложения
Почему этот "специальный компонент" не могет назначить права для одной базы?

>Во-первых - могут быть обособленные базы для разных районов.
И отдельно общая городская? Или по городу уже не интересно? ИМХО, в рамках одной БД проще получать такую инфу.

>Во-вторых - базы очень быстро разбухают.
Насколько быстро и насколько разбухают? И потом. По твоему писать и читать из/в несколько баз сервер (он же один!) будет быстрее чем в одну. По моему наоборот.

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

ИМХО, в системах подобного уровня надо бы использовать что нибудь покруче ИБ. Тем паче что потери инфы, как я понял, не допустимы. У ИБ в этом плане набор возможностей не ахти какой. Да он очень устойчив, но уж если полетела база, то все - только откат на последний бэкап (а когда он был?) поможет.

>Sergey13 © (13.05.04 10:40) [10]

Это выстраданные решения, продиктованные финансовыми возможностями заказчика. Самая первая версия была вообще сделана на Windows 3.11 (аналогичные системы советского производства вообще до сих пор работают под DOS или даже на EC ЭВМ) :)

Система программно-аппаратная распределенная с несколькими уровнями резервирования. Возможностей IB пока вполне хватает, в случае необходимости элементарно перейти на что-нибудь помощнее...

> только откат на последний бэкап

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

> каждая хранит информацию об определенном тренажерном комплексе

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

Да, сервер БД - это всего лишь один из компонентов системы, важный, но не основной...

2y-soft © (13.05.04 10:50) [11]
>Это выстраданные решения, продиктованные финансовыми возможностями заказчика.
Скорее его жадностью. Для покупки мерсов руководству денег хватает обычно. Но это мысли для дугого форума. 8-)

Про нужность многобазия 8-) вы меня не убедили. Я остаюсь при своем мнении - одна лучше.

>Sergey13 © (13.05.04 10:59) [14]

Ну, не всем же достаются богатые щедрые заказчики. Кому-то, вот, милиционеры и коммунальщики :)

P.S. На "многобазии" не настаиваю. Настаиваю на многовариантности подходов :)

Список БД в InterBase/FireBird Найти похожие ветки