Думаю, для большинства СУБД соединение - это host(:port), а внутри

него уже можно иметь разные права на разные dbname

а у FB к идентификатору соединения, видимо, привязывается ещё dbname ?

Для FB не так. Законнектиться к просто серверу - нельзя, можно только сразу к базе.

ага, так и понял, поправил мессагу

Ну тогда еще протокол забыл :) Тоже бывает нужно указать.

и зачем же вы его пользуете такого? ))) какие у него плюсы есть по сравнению с PG, например (если вам MySQL не по нраву) ?

1. Ни разу не было проблемы от того что в FB нет коннекта к собственно серверу. Просто особенности архитектуры. 2. Я лет 30 назад начал с IB4.2.1, потом IB6.0, Yaffil, Firebird. Мозг заточен под особенности Firebird, довольно большое кол-во процедур, триггеров. Если бы начинал сейчас с нуля - то может быть смотрел бы в сторону PosgreSQL, но в те времена он был в зачаточном состоянии. А сейчас переезжать с одного сервера на другой нет никакого ни экономического ни практического смысла. 3. Но наши питонисты используют постресс.

У Firebird есть концепция В одном коннекте может быть N транзакций В транзакции может быть N запросов. Все это работает одновременно. Вспоминаю начало работы с Interbase через BDE где ничего этого не поддерживалось, и какие проблемы создавало, и когда я перешел на компоненты доступа где это поддерживалось - это просто счастье. Насколько я в курсе, далеко не в каждом сервере такое есть, и как там работать после FB - х.з.

хм, зачем N транзакций? я вот вообще ими не пользуюсь )

BDE... В dbExpress классную подставку сделали. В dbx3 была поддержка множественные транзакций. А в dbx4 её тихо убрали. Там сделали только вложенные транзакции, и завершение ранней транзакции тихо убивает все транзакции-дети. ...но интерфейс оставили как было. Типо якобы множественные транзакции бывают. Чтобы компиляции не ломалась. Пусть потом а рантайме все ломается, так веселее...

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

нет предела совершенству защиты от дурака )

Это невозможно, начнёшь запрещать ddl, он тебе данные обнулит 😁

Если БД расположены на одном и том же физическом сервере, и сильно связаны, то возникает вопрос а посему это разные БД. Вот чего действительно жаль. что Firebird не имеет схем, потому что если встречается вышеописанное. то это скорее схемы в одной и той же БД, чем разные БД

"сильно" - это не по-инженерски ) просто есть связь, какая разница почему и зачем? БД могут реплицироваться из разных мест, но структура идентичная... а может быть разное ПО делает разные БД, но логически они связаны какими-то ключами через НСИ...

это как раз по инженерски. Проектировщик всегда должен думать нужно ли ему размещать данные в нескольких БД или лучше одной. И заметь тут речь не о репликации, поэтому про одинаковую структуру тут мимо. Я к тому что если есть задача из одной БД часто обращаться в другую, то что-то здесь не так. И не надо мне заливать про то что это умеет кто-то там. Так как они это умеют, даже если и удобней чем ФБ, то работает крайне не эффективно. А из ФБ я тоже могу подключиться хоть в MSSQL, хоть в PG. но только с помощью ODBCEngine плагина, который писал для IBSurgeon

Тут наверное вопрос, есть ли принципиальнгая связь между межпоточным и межпроцессным взаимодействием. Судя по Firebird Classic - нет. Теперь добавляем автоматическое распараллеливание запроса по ядрам, которое в MS SQL есть. Получаем, что даже простейший запрос select count(*) с точки зрения кода сервера - межпроцессное взаимодействие. Проверка транзакций, слияние потоков данных и вот это всё - всегда пишутся под многопроцесс. Ну а если оно уже так так, то почему бы бонусом не добавить потоки данных из другой БД, которую обслуживает тот же инстанс сервера? технически-то разницы с автоматическим распараллеливанием внутри одной БД уже почти и нет.

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

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

если что, в MySQL create schema == create database )

Чего тут понимать. Если нужно раз в минуту сползать в другую БД за данными, то это не сильная связь. А вот когда начинают там всяческие JOIN городить, да и интенсивность по 1000 обращений в соседнюю БД в секунду. Значит БД уже не должны быть разными, если они находятся на одном сервере.

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

это их половые трудности. В ФБ это тоже синонимы, потому что настоящих схем нет. MySQL как обычно клал на стандарт и делает свои костыли

его оракул, упомянутый выше, делает )

схема - это насколько понимаю namespace с правами доступа, что-то слегка подобное в fb3 как package я в данном случае говорил именно про доступ к БД лежащих в других файлах и возможно обслуживаемое другой копией того же сервера. Почему это обязано быть неэффективным? В том же MySQL каждая таблица - отдельные файл, и ничего, нитко не говорит что это разные БД. Просто надо разделять доступ через ODBC-подобные абстракции, где у нас получается черный ящик с 2D-матрицей на выходе, считай как с DBF джойнить, и доступ к БД родного для сервера формата, просто лежащей в другом файле. При условии, что у меня рядыщком лежат 1.fdb и 2.fdb и открываются они одним инстансом fbserver - почему джойн между БД обязан быть менее эффективным, чем джойн внутри одно БД?

Это к теме не относится. Для бд есть 2 крайности: 'Умная' и нагруженная свойствами аппсервера. И упрщенное до безобразия хранилище DTO. Остальное в разной степени между ними. Часто идут на сознательный отказ от возможностей СУБД. Н-р кэшируя справочники и расшифровывая их на клиенте. Микросервисов опять-таки.