Firebird - jak wykonac zapytanie na dwoch bazach
Marcin Dworzañski
Jak majac dwie oddzielne bazy (pliki .gdb) wykonac zapytanie na tabelach
z obydwu baz?
przykladowo typowe zlaczenie, ale co istotne NA TABELACH Z DWOCH ROZNYCH
BAZ:
SELECT Baza1.gdb->Tabela1.nazwa, Baza2.gdb->Tabela2.nazwa
FROM Baza1.gdb->Tabela1, Baza2.gdb->Tabela2
WHERE Tabela2.ID=Tabela1.Numer
Baza Interbase (serwer Firebird)
Dodam, ze w glupim Paradoxie dawalo sie to, a tutaj jakos nie moge
Piotrek
>
Piotrek.
Marcin Dworzañski
Piotrek wrote:
Nie wierze!
Nikt nigdy sie nie spotkal z takim problemem??
Czy zatem projektant skazany jest na tworzenie jednej olbrzymiej bazy
danych i trzymania w niej wszelakich tabel niezaleznie od tego jakie
jest ich przeznaczenie?
Problem powstaje gdy na calosc skladaja sie tabele "konfiguracyjne"
(ktorych dane niewiele sie zmieniaja), oraz tabele "zywe" (ktore
polykaja wielkie ilosci rekordow i sie rozdymaja do duzych rozmiarow)
Chyba naturalne jest tworzenie osobnych baz na oba rodzaje tabel, chocby
dlatego ze tabele "zywe" maja znacznie wieksze prawdopodobienstwo
wygenerowania bledow w pliku
Moze istnieje jakis nadrzedny mechanizm ktory w SQL-u moze polaczyc
tabele z osobnych baz?
Zbyszek Zarzycki
--
Uzytkownik "Marcin Dworzański" <mdwo...@stemro.com.pl> napisal w wiadomosci
news:4098DF0A...@stemro.com.pl...
> Nikt nigdy sie nie spotkal z takim problemem??
>
Owszem, np. projektanci systemów bankowych gdy chca spiac ze soba bazy dwóch
banków.
> Czy zatem projektant skazany jest na tworzenie jednej olbrzymiej bazy
> danych i trzymania w niej wszelakich tabel niezaleznie od tego jakie
> jest ich przeznaczenie?
>
Skazany nie, powinien tak.
> Chyba naturalne jest tworzenie osobnych baz na oba rodzaje tabel,
Naturalne? W sztucznym swiecie cos naturalnego? Nie da rady ;)
> Moze istnieje jakis nadrzedny mechanizm ktory w SQL-u moze polaczyc
> tabele z osobnych baz?
>
W IB takiem mechanizmem jest UDF.
Ale zanim zaczniesz narzekac jakie to wolne to przemysl powody dla których
tak jest, pierwsze z brzegu:
- baza danych to instancja serwera SQL
- kazda baza wymaga oddzielnej autoryzacji
- komunikacja miedzy serwerami jest dodatkowym zagrozeniem dla
bezpieczenstwa
- komunikacja miedzy serwerami wymaga polaczenia wyników pracy dwóch
niezaleznych bytów.
Bazy SQL to nie pliki a przede wszystkim procesy które wydobywaja z danych
potrzebne informacje.
--
Zbyszek Zarzycki
BSC Polska
Wszystko o narzedziach Borlanda:
http://www.borland.pl/bdd2004
PaSkol
> Czy zatem projektant skazany jest na tworzenie jednej olbrzymiej
> bazy danych i trzymania w niej wszelakich tabel niezaleznie od tego
> jakie jest ich przeznaczenie?
Jeśli tabele mają być ze sobą w relacji - tak. Takim przykładem może
być tabela stawek VAT powiązana z tabelą towarów, a jeszcze lepiej -
pozycji dokumentów. VAT jest taką tabelą "konfiguracyjną" - tu dane
właściwie się nie zmieniają, natomiast pozycje dokumentów przyrastają,
przyrastają, przyrastają, ... (to ta "żywa" tabela).
> Problem powstaje gdy na calosc skladaja sie tabele "konfiguracyjne"
> (ktorych dane niewiele sie zmieniaja), oraz tabele "zywe" (ktore
> polykaja wielkie ilosci rekordow i sie rozdymaja do duzych
> rozmiarow)
Jeśli tabele rzeczywiście są "konfiguracyjne" (np. przechowywanie
ustawień interfejsu programu, historii wpisywanych tekstów, itp.) to
można je trzymać w oddzielnej bazie ze świadomością konsekwencji tego
rozwiązania (jak opisał to Pan Zarzycki). Ale jeśli tylko mają mieć
jakieś powiązanie z tabelami z "głównej" bazy - trzeba je trzymać w
niej.
> Chyba naturalne jest tworzenie osobnych baz na oba rodzaje tabel,
> chocby dlatego ze tabele "zywe" maja znacznie wieksze
> prawdopodobienstwo wygenerowania bledow w pliku
Na błędy tabel pomaga kopia bezpieczeństwa. Zaś rozdzielenie danych od
siebie jako sposób na poprawienie ich bezpieczeńtwa (i to jakkolwiek
rozumianego) ma bardzo krótkie nogi - można tego próbować w bazach
Desktop, ale C/S to inna filozofia - zatem inne metody ochrony danych
przed "uszkodzeniem".
Może napisz konkretnie co chciałbyś odseparować od siebie - może
okazać się, że istnieją solidne argumenty, by przekonać Cię, że nie ma
to sensu.
--
PaSkol
---=== Każdy usenetowy chwat z Netykietą za pan brat ===---
---=== http://www.pg.gda.pl/~agatek/netq.html ===---
Marcin Dworzañski
> okazać się, że istnieją solidne argumenty, by przekonać Cię, że nie ma
> to sensu.
>
> --
> PaSkol
> ---=== Każdy usenetowy chwat z Netykietą za pan brat ===---
> ---=== http://www.pg.gda.pl/~agatek/netq.html ===---
Przede wszystkim dziekuje za kompetentne odpowiedzi :)
Co do moich zalozen, to chodzi o to, ze jest sobie jakis system
informatyczny X, ktory posiada w bazach zapisane roznorodne elementy (np
pracownicy, towary, pojazdy, konfiguracja, itp). Te dane sa raczej
statyczne - nie ma rotacji pracownikow rzedu kilkuset dziennie ;)
Oprocz tych tabel, jest jeszcze jedna tabela w ktorej przechowywane sa np
zdarzenia wygenerowane przez pracownikow (np roznorodne czynnosci, itp).
Oczywiscie zdarzenia przybywaja baaardzo solidnie i po np miesiacu moze
tego przyrosnac pare milionow rekordow (przy praktycznie zerowym
przyroscie pozostalych tabel)
Wydawalo mi sie naturalne, aby te tabele umiescic w osobnej bazie (osobnym
pliku), gdyz jakakolwiek awaria komputera doprowadzi natychmiast do
popsucia tej bazy (czeste zapisy) - tego zjawiska juz doswiadczylem.
Tabelki bardziej statyczne, sa odporniejsze na problemy z komputerem.
Sprawy zwiazane z bezpieczenstwem dostepu do danych byly dla mnie mniej
istotne (choc moze wcale takie malo istotne nie sa)
Ja widze tu zalete rozdzielenia baz. Chetnie zapoznam sie z innymi
wypowiedziami, bo sie przy takim rozwiazaniu nie upieram. Wazne jest dla
mnie zabezpieczenie danych przed fizycznym popsuciem (moze wystarczy
porzadny komputer jako serwer bazodanowy, bez innych aplikacji?)
- Jak najlepiej zabezpieczyc sie przed skutkami problemow z komputerem
(pokaszanione bazy)?
- Jak wykonac backup, a nastepnie usuniecie kilku milionow rekordow (np z
zeszlego miesiaca), nie przerywajac dzialania systemu? Dostep do tych
zarchiwizowanych rekordow juz wogole stoi pod znakiem zapytania majac caly
system na jednej bazie...
Pozdrawiam,
Marcin
Sławomir Niedziela
> Co do moich zalozen, to chodzi o to, ze jest sobie jakis system
> informatyczny X, ktory posiada w bazach zapisane roznorodne elementy (np
> pracownicy, towary, pojazdy, konfiguracja, itp). Te dane sa raczej
> statyczne - nie ma rotacji pracownikow rzedu kilkuset dziennie ;)
>
> Oprocz tych tabel, jest jeszcze jedna tabela w ktorej przechowywane sa np
> zdarzenia wygenerowane przez pracownikow (np roznorodne czynnosci, itp).
> Oczywiscie zdarzenia przybywaja baaardzo solidnie i po np miesiacu moze
> tego przyrosnac pare milionow rekordow (przy praktycznie zerowym
> przyroscie pozostalych tabel)
Zastanawiałem się nad podobnym zagadnieniem i na razie zainteresowała mnie
idea EXTERNAL FILE. Nie ćwiczyłem jeszcze tego ale wydaje mi się, że mi to
wystarczy.
--
Sławek
Martini
> Co do moich zalozen, to chodzi o to, ze jest sobie jakis system
> informatyczny X, ktory posiada w bazach zapisane roznorodne elementy (np
> pracownicy, towary, pojazdy, konfiguracja, itp). Te dane sa raczej
> statyczne - nie ma rotacji pracownikow rzedu kilkuset dziennie ;)
>
> Oprocz tych tabel, jest jeszcze jedna tabela w ktorej przechowywane sa np
> zdarzenia wygenerowane przez pracownikow (np roznorodne czynnosci, itp).
> Oczywiscie zdarzenia przybywaja baaardzo solidnie i po np miesiacu moze
> tego przyrosnac pare milionow rekordow (przy praktycznie zerowym
> przyroscie pozostalych tabel)
>
> Wydawalo mi sie naturalne, aby te tabele umiescic w osobnej bazie (osobnym
> pliku), gdyz jakakolwiek awaria komputera doprowadzi natychmiast do
> popsucia tej bazy (czeste zapisy) - tego zjawiska juz doswiadczylem.
>
> Tabelki bardziej statyczne, sa odporniejsze na problemy z komputerem.
Najrozsadniejsza podpowiedzia wydaje mi sie kopia bezpieczenstwa. Skoro
jednak upierasz sie przy osobnych bazach:
- stwórz baze statyczna
- w tej zywej stwórz kopie struktur tabel ze statycznej i kopiuj do niej
dane ze statycznej, np. w czasie uruchamiania programu, lub uzupelniaj dane
w razie zmiany danych w statycznej
- majac taki mirror unikniesz uszkodzenia tej mniejszej, a do tego dazysz
prawda?
pozdrawiam
Martini
mart...@wp.pl
Marcin Dworzañski
> w razie zmiany danych w statycznej
> - majac taki mirror unikniesz uszkodzenia tej mniejszej, a do tego dazysz
> prawda?
>
> pozdrawiam
> Martini
> mart...@wp.pl
Wedlug mnie jest jeszcze jeden powod realizacji systemu na kilku oddzielnych
bazach: Pojedyncza baza danych ma pewna maksymalna przepustowosc (dajmy na to
okolo 300 zapisow rekordow na sekunde (rekord ma okolo 100B) ). W przypadkach
gdy wymagana przepustowosc jest wyzsza, chyba jedynym rozwiazaniem jest rozbicie
systemu na kilka niezaleznych serwerow (zlokalizowanych na osobnych
komputerach).
Mozna skalowac przepustowosc inaczej?
wloochacz
oddzielnych
> bazach: Pojedyncza baza danych ma pewna maksymalna przepustowosc (dajmy na
to
> okolo 300 zapisow rekordow na sekunde (rekord ma okolo 100B) ). W
przypadkach
> gdy wymagana przepustowosc jest wyzsza, chyba jedynym rozwiazaniem jest
rozbicie
> systemu na kilka niezaleznych serwerow (zlokalizowanych na osobnych
> komputerach).
> Mozna skalowac przepustowosc inaczej?
kilka baz [no chyba, ze ktos myli encje/tabele z pojeciem baza].
Paza tym nie mozesz traktowac SZBD jak prostej bazy plikowej, to nie ta
zabawka...
Skalowalnosc zalezy od wielu czynników, poza tym baza danych to nie system
czasu rzeczywistego no i 300 transakcji na sekunde to... wcale nie jest duzo
[zobacz:
http://www.tpc.org/tpcc/results/tpcc_results.asp?print=false&orderby=tpm&sortby=desc]
Wiec po co dzielic projekt na wiele baz, skoro wiecej z tym problemów niz
pozytku??
Oczywiscie mówimy w konkescie FB/IB, bo nie wszystkich baz SZBD takie
ograniczenie dotyczy.
---
wloochacz
Kamil K.
>
> Jak majac dwie oddzielne bazy (pliki .gdb) wykonac zapytanie na tabelach
> z obydwu baz?
>
>
> Dodam, ze w glupim Paradoxie dawalo sie to, a tutaj jakos nie moge
Dziala po przez BDE, sprawdzalem.
Kmail.