Firebird работа с двумя базами

← →
Danilka © (2004-08-27 15:28) [40]

[39] Труп Васи Доброго © (27.08.04 14:53)
Перейти на СУБД, которая позволяет так делать :)
А вообще, см [32] Desdechado © (26.08.04 21:32) п.2
:))

[35] nikkie © (27.08.04 00:38)
> недавно показывали по телику мужика из Самары, кажется -
> он способен обнаружить тысячи угнанных машин, не выходя
> из дома, сличая несколько баз - базу vin-номеров от производителей,
> базу машин, числящихся в угоне и базу зарегистрированных
> машин по России.

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

← →
nikkie © (2004-08-27 15:49) [41]

>Труп Васи Доброго
>Неужели никто не думал о том, что это надо (работать с двумя базами)!?!?!?
>Может какие идеи у кого появились как выйти из этой ситуации, мыслишки мож какие?
типа, все, выступавшие выше, просто трепом занимались. блин.

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

Самое простое, сделать экспорт в одну базу необходимых табличек, и уже по ним искать.
не думаю, что это самое простое. реализация join двух таблиц из разных баз на уровне приложения - дело 5 минут.

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

← →
Игорь Шевченко © (2004-08-27 15:50) [42]

> Перейти на СУБД, которая позволяет так делать :)

Например, на Oracle. Он позволяет

← →
Esu (2004-08-27 15:56) [43]

MSSQL тоже позволяет...

← →
jack128 © (2004-08-27 15:59) [44]

> реализация join двух таблиц из разных баз на уровне
> приложения - дело 5 минут.

select Mens.FIO
from Mens, Auto
where Mens.AutoId = Auto.Id and Auto.Mark = "Волга"
таблица Mens - в одной базе, Auto - в другой. Волг в базе пара тысяч. И как? Выберем мы все Id волг, а дальше что? Что то мне кажется, что запрос "select Mens.FIO from Mens where Mens.AutoId in (тут список из пары тысяч чисел)" не очень быстро будет выполняться...

← →
nikkie © (2004-08-27 16:06) [45]

>jack128
избалован народ sql-ем... а подумать если? как до sql join делали? открываем два согласованных индекса и синхронно по ним движемся. для sql базы - 2 запроса с одинаковыми order by.

← →
Danilka © (2004-08-27 16:16) [46]

[41] nikkie © (27.08.04 15:49)
> а представь, что у тебя есть 2 живых системы, которые активно
> обновляют разными базами. ты будешь постоянно эти две базы
> в одну сливать или предпочтешь работать с двумя разными?

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

[42] Игорь Шевченко © (27.08.04 15:50)
> Например, на Oracle. Он позволяет

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

← →
jack128 © (2004-08-27 16:24) [47]

nikkie © (27.08.04 16:06) [45]
как до sql join делали? открываем два согласованных индекса и синхронно по ним движемся. для sql базы - 2 запроса с одинаковыми order by
До SQL - это когда по земле бродили динозавры? Меня тогда еще не было.. Сенкс.

← →
Danilka © (2004-08-27 16:27) [48]

[45] nikkie © (27.08.04 16:06)
Тащить все на клиента - не лучший вариант. Конечно, если он один с этими базами работает, и сервер на его машине, то.. :))

← →
nikkie © (2004-08-27 17:04) [49]

>Danilka
>Тащить все на клиента - не лучший вариант. Конечно, если он один с этими базами работает, и сервер на его машине, то.. :)

никто не мешает запускать приложение на сервере. можно средним уровнем сделать.

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

я бы сказал, что клиент-сервер и вообще sql базы - это не панацея. и прежде, чем бросаться заливать все в свой любимый <подставить на выбор - IB, MS SQL, Oracle, ...>, стоит подумать.

← →
Игорь Шевченко © (2004-08-27 17:08) [50]

nikkie © (27.08.04 17:04) [49]

> стоит подумать.

И не размещать нужные одновременно данные в двух разных базах :)

← →
nikkie © (2004-08-27 17:32) [51]

>И не размещать нужные одновременно данные в двух разных базах :)

даешь одну Универсальную Базу (УБ)! :)

а потом на основе УБ Дм.О.-чу будет легче Матрицу сделать. :))

кстати, хорошо бы, чтобы новая версия конвектора форматов умела данные в УБ заливать.

← →
Игорь Шевченко © (2004-08-27 17:33) [52]

> а потом на основе УБ Дм.О.-чу будет легче Матрицу сделать.
> :))

Да она глючить будет...

Сервер один, баз две (пока две) и приложений, которые работают с этими базами два (каждое со своей)(Т.е. два различных приложения на нескольких клиентах), но вот в каждой базе есть одна одинаковая(!!!) таблица, по которой надо делать запрос к обеим базам из третьего приложения.
Пока никаких реальных предложений нет :(

> баз две (пока две)

Пока не поздно переделать...

> Пока не поздно переделать...

Поздно, это базы абонентской службы, там данные за три года. Причём это же нельзя остановить, деньги то с абонентов брать надо.

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

>надо делать запрос к обеим базам из третьего приложения.
так из ХП или из приложения? определись-таки ...

>Пока никаких реальных предложений нет
а как тебе вариант 3 из [32]? пробовал? или просто лень?

Firebird работа с двумя базами Найти похожие ветки