[SQL server] Polaczenie miedzy bazami?
Mikolaj Rydzewski - 23-11-2006 00:11
[SQL server] Polaczenie miedzy bazami?
Witam,
Sa sobie trzy aplikacje, kazda pracuje na swojej bazie danych. Tak sie jednak sklada, ze jedna tabela w kazdej z tych baz jest wspolna. Tzn. powinna byc wspolna. Jest to dosyc spory slownik, od czasu do czasu aktualizowany. Rzecz jasna istnieja do niego klucze obce w kazdej z baz.
Jak to najlepiej rozwiazac:
- recznie/automatycznie synchronizowac tabele we wszystkich bazach - faktyczna tabele miec tylko w jednej bazie, w pozostalych utworzyc widok odwolujacy sie do wlasciwej tabeli - zmigrowac trzy bazy do jednej, kazda do innego schematu i takze skorzystac z widoku
Pierwsze rozwiazanie jest najgorsze ;-)
Drugie: czy moge w SQL Serwerze odwolac sie z jednej bazy do drugiej? W sensie utworzenia widoku siegajacego do tabeli z innej bazy.
Trzecie: widoki pomiedzy schematami jednej bazy mozna robic. Tylko czy daloby sie prosto przeniesc dane z juz istniejacej bazy do schematu w nowej?
-- Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/ PGP KeyID: 8b12ab02 There are three kinds of people: men, women, and unix.
Marcin A. Guzowski - 23-11-2006 00:12
Mikolaj Rydzewski napisał(a): > Witam, > > Sa sobie trzy aplikacje, kazda pracuje na swojej bazie danych.
Wszystkie z tych baz są na jednym SQLu czy może na kilku maszynach?
Tak sie > jednak sklada, ze jedna tabela w kazdej z tych baz jest wspolna. Tzn. > powinna byc wspolna. Jest to dosyc spory slownik, od czasu do czasu > aktualizowany.
W jaki sposób odbywa się aktualizacja? Robią to te aplikacje (jedna z nich), czy może proces zewnętrzny?
Rzecz jasna istnieja do niego klucze obce w kazdej z baz. > > Jak to najlepiej rozwiazac: > > - recznie/automatycznie synchronizowac tabele we wszystkich bazach > - faktyczna tabele miec tylko w jednej bazie, w pozostalych utworzyc > widok odwolujacy sie do wlasciwej tabeli > - zmigrowac trzy bazy do jednej, kazda do innego schematu i takze > skorzystac z widoku > > Pierwsze rozwiazanie jest najgorsze ;-)
Niekoniecznie.
> Drugie: czy moge w SQL Serwerze odwolac sie z jednej bazy do drugiej? W > sensie utworzenia widoku siegajacego do tabeli z innej bazy.
Oczywiście, przecież masz działające na tej zasadzie klucze obce. Jeżeli jednak widok ma sięgać do obiektów z innej bazy, to użytkownik (rola), który z widoku będzie korzystał - musi mieć odpowiednie prawa do wszystkich obiektów, z których budowany jest widok (nie wystarczy dodanie praw do samego widoku).
> Trzecie: widoki pomiedzy schematami jednej bazy mozna robic. Tylko czy > daloby sie prosto przeniesc dane z juz istniejacej bazy do schematu w > nowej?
Dane przenosi się bardzo prosto. Natomiast nie bardzo rozumiem, o co Ci chodzi w powyższy zdaniu :) Schemat nie jest miejscem przechowującym obiekty - grupuje tylko je dając możliwość ustalania im wspólnych cech. Nie napisałeś jakiej wersji SQL Servera używasz, a to może mieć spore znaczenie.
Nie bardzo da się wybrać dobre rozwiązanie na podstawie informacji, które dostarczyłeś. Poza pytaniami, które zadałem - rozważyć trzeba jeszcze np. politykę uprawnień czy choćby charakterystykę pracy aplikacji (jak każda z nich korzysta z tych tabel).
-- Pozdrawiam, Marcin Guzowski http://guzowski.info
Mikołaj Rydzewski - 23-11-2006 00:12
Marcin A. Guzowski wrote: > Mikolaj Rydzewski napisał(a): >> Sa sobie trzy aplikacje, kazda pracuje na swojej bazie danych. > > Wszystkie z tych baz są na jednym SQLu czy może na kilku > maszynach?
Tak, sa to trzy bazy na jednym SQL Server 2005. Sa to aplikacje webowe pracujace na jednym Tomcacie. I kazda z nich stanowi jedna czesc pewnego projektu, tzn. kazda z aplikacji (a tym samym kazda z baz) zbiera dane troche innego rodzaju, powiazanych jednak wspolna tabela slownikowa.
Przyklad: bazy autobusy i tramwaje ze wspolnym slownikiem miasto. Sluza do katalogowania jakie autobusy i tramwaje jezdza w danym miescie. A raporty pokazywalyby np. wszystkie wpisy dla danego miasta.
> Tak sie >> jednak sklada, ze jedna tabela w kazdej z tych baz jest wspolna. Tzn. >> powinna byc wspolna. Jest to dosyc spory slownik, od czasu do czasu >> aktualizowany. > > W jaki sposób odbywa się aktualizacja? > Robią to te aplikacje (jedna z nich), czy może proces zewnętrzny?
Aktualizacja jest zewnetrzna (i sporadyczna). Dla aplikacji slowniki sa tylko do odczytu.
>> Pierwsze rozwiazanie jest najgorsze ;-) > > Niekoniecznie.
Mam na uwadze tworzenie raportow, ktore predzej czy pozniej bedzie musialo byc. Jednolity (w sensie wartosci klucza) glowny slownik uproscilby wg mnie raporty.
>> Drugie: czy moge w SQL Serwerze odwolac sie z jednej bazy do drugiej? W >> sensie utworzenia widoku siegajacego do tabeli z innej bazy. > > Oczywiście, przecież masz działające na tej zasadzie klucze obce. > Jeżeli jednak widok ma sięgać do obiektów z innej bazy, to użytkownik > (rola), który z widoku będzie korzystał - musi mieć odpowiednie prawa > do wszystkich obiektów, z których budowany jest widok (nie wystarczy > dodanie praw do samego widoku).
To nie jest problem.
>> Trzecie: widoki pomiedzy schematami jednej bazy mozna robic. Tylko czy >> daloby sie prosto przeniesc dane z juz istniejacej bazy do schematu w >> nowej? > > Dane przenosi się bardzo prosto. Natomiast nie bardzo rozumiem, o co Ci > chodzi w powyższy zdaniu :) Schemat nie jest miejscem przechowującym > obiekty - grupuje tylko je dając możliwość ustalania im wspólnych cech.
Hmm... No ale moge chyba zrobic 'create table' w schemacie? Tak jak w postgresie np?
Teraz mam taka sytuacje: baza_A, baza_B, baza_C. W kazdej z nich jest ta nieszczesna wspolna tabela (T).
Tak naprawde chodzi mi tylko o dwie rzeczy: - synchronizacje tej jednej tabeli miedzy bazami, - ulatwienie raportowania, ktore predzej czy pozniej bedzie robione
Na pewno beda raporty zbierajace dane ze wszystkich baz w powiazaniu do tabeli T. Doszedlem do wniosku, ze prosciej robic raporty gdy wszystkie dane sa w jednej bazie niz w kilku. Poniewaz wrzucenie wszystkich tabel do jednej bazy nie wchodzi w gre (konflikty nazw), pomyslalem o rozdzieleniu bazy na schematy. Wtedy w aplikacji zmienie tylko w pliku konfiguracyjnym parametr polaczenia do bazy, a raporty pojda bez problemu.
> Nie napisałeś jakiej wersji SQL Servera używasz, a to może mieć > spore znaczenie.
MS SQL 2005.
> Nie bardzo da się wybrać dobre rozwiązanie na podstawie informacji, > które dostarczyłeś. Poza pytaniami, które zadałem - rozważyć trzeba > jeszcze np. politykę uprawnień czy choćby charakterystykę pracy > aplikacji (jak każda z nich korzysta z tych tabel).
Polityka uprawnien jest prosta jak drut ;-) Do bazy laczy sie tylko Tomcat poprzez JDBC. Wspolna baza mialaby jeszcze te zalete, ze potrzebna bylaby tylko jedna pula polaczen a nie trzy.
Dzieki za odpowiedz. Czy cos jeszcze chcesz wiedziec?
-- Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/ PGP KeyID: 8b12ab02 There are three kinds of people: men, women and unix.
Marcin A. Guzowski - 24-11-2006 00:03
Mikołaj Rydzewski napisał(a): > Polityka uprawnien jest prosta jak drut ;-) Do bazy laczy sie tylko > Tomcat poprzez JDBC. Wspolna baza mialaby jeszcze te zalete, ze > potrzebna bylaby tylko jedna pula polaczen a nie trzy.
I wszystko jasne. Myślisz o SQL Serverze jak o PostgreSQL, gdzie występują głupie według mnie ograniczenia, że nie można się na jednym połączeniu odwoływać do więcej niż jednej bazy danych. (stąd 3 pule połączeń, podczas gdy z SQL Serverem można spokojnie rozmawiać wyłącznie na jednej puli).
SQL Server to zupełnie inna filozofia niż PGSQL. Tu nie łączysz się do konkretnej bazy danych, a do instancji, a kontekst bazy zmieniasz sobie dowolnie - będąc ograniczanym wyłącznie przez uprawnienia.
Czyli nie potrzeba widoków w dwóch bazach do tabeli w jednej, nie potrzeba replikacji ani kombinacji ze schematami (chyba że rzeczywiście chcesz wszystko mieć w jednej bazie, ale z różnych względów prawdopodobnie nie ma takiej potrzeby).
Użytkownik tomcata już pewnie ma odpowiednie prawa do wszystkich baz, bo inaczej nic by Ci nie działało.
Aplikacja 2 (ze swoją bazą B), będąc w kontekście bazy B może spokojnie wywołać selecta do bazy A:
SELECT * FROM A.schemat.Slownik; (schemat w której istnieje tabela, domyślnie dbo)
Wymagać to może minimalnych modyfikacji w kodzie aplikacji (np. dodania w pełni kwalifikowanej nazwy obiektu - nazwa bazy + schemat + nazwa tabeli). Jeżeli chcesz uniknąć za wszelką cenę modyfikacji w kodzie aplikacji, to usuń z dwóch baz tabele słownikowe i stwórz widoki o takiej samej nazwie, odwołujące się do jedynej ocalałej tabeli słownikowej.
-- Pozdrawiam, Marcin Guzowski http://guzowski.info
Marcin 'goral' Goralski - 25-11-2006 00:06
Mikołaj Rydzewski wrote:
> Przyklad: bazy autobusy i tramwaje ze wspolnym slownikiem miasto. Sluza > do katalogowania jakie autobusy i tramwaje jezdza w danym miescie. A > raporty pokazywalyby np. wszystkie wpisy dla danego miasta.
To chyba niespecjalnie dobry przyklad. Przeciez i autobus i tramwaj :: srodek_lokomocji czy jak to zwiesz, po co trzymac to w oddzielnych schematach czy bazach ? Jak dla mnie, cos tu jest nie tak z samym projektem.
> Teraz mam taka sytuacje: baza_A, baza_B, baza_C. W kazdej z nich jest ta > nieszczesna wspolna tabela (T).
A powinienes miec jedna baze i kilka tablic (m.in 3,jak sadze) i odpowiednie relacje miedzy nimi.
> Na pewno beda raporty zbierajace dane ze wszystkich baz w powiazaniu do > tabeli T. Doszedlem do wniosku, ze prosciej robic raporty gdy wszystkie > dane sa w jednej bazie niz w kilku. Poniewaz wrzucenie wszystkich tabel > do jednej bazy nie wchodzi w gre (konflikty nazw), pomyslalem o > rozdzieleniu bazy na schematy. Wtedy w aplikacji zmienie tylko w pliku > konfiguracyjnym parametr polaczenia do bazy, a raporty pojda bez problemu.
Przeprojektuj to porzadnie i zniknie problem konfliktu nazw. Warto zrobic porzadny projekt.
marcin
Mikolaj Rydzewski - 25-11-2006 00:06
Marcin 'goral' Goralski <goralski.marcin@bez.smieci.wp.pl> wrote:
> Przeprojektuj to porzadnie i zniknie problem konfliktu nazw. Warto > zrobic porzadny projekt.
Tyle teorii, dziekujemy.
Prawdziwe zycie posiada jednak swoja specyfike. Chocby taka, ze klient (sam do konca nie wiedzac czego chce) zleca podmoduly, ktore - co okazuje sie na samym koncu - maja ze soba wspolpracowac.
Niestety po fakcie i produkcyjnym uruchomieniu juz dostarczonych aplikacji ciezko jest cokolwiek zmienic. Tm bardziej, ze za to juz klient nie zaplaci. Za to za modul do synchronizacji slownikow owszem... Ale to juz inna bajka.
-- Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/ PGP KeyID: 8b12ab02 There are three kinds of people: men, women, and unix.
Mikolaj Rydzewski - 25-11-2006 00:06
Marcin A. Guzowski <tu_wstaw_moje_imie@guzowski.info> wrote:
> Wymagać to może minimalnych modyfikacji w kodzie aplikacji > (np. dodania w pełni kwalifikowanej nazwy obiektu - nazwa > bazy + schemat + nazwa tabeli). Jeżeli chcesz uniknąć za > wszelką cenę modyfikacji w kodzie aplikacji, to usuń z dwóch > baz tabele słownikowe i stwórz widoki o takiej samej nazwie,
Dzieki za wyjasnienie. Tabela w jednej bazie + widoki w pozostalych to bedzie dobre rozwiazanie.
-- Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/ PGP KeyID: 8b12ab02 There are three kinds of people: men, women, and unix.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Jak =?windows-1250?Q?pobra=E6_szacowan=B9_wielko=9C=E6_zbiory_wy nikowego_w_MS?==?windows-1250?Q?_SQL_2005=3F?=
=?iso-8859-2?Q?=5BMS_SQL=5D_Czy_mo=BFna_wywo=B3a=E6_funkcje_t ylko_raz_dla?==?iso-8859-2?Q?_ca=B3ego_zbioru_=BCr=F3d=B3owego=3F?=
=?ISO-8859-2?Q?k=B3opot_z_uruchomieniem_MY_SQL_dla_C?==?ISO-8859-2?Q?MS_i_CRM_na_Fedora_Core_3?=
Oracle PL/SQL Wstawianie =?ISO-8859-2?Q?wynik=F3w_kolekcji_d?==?ISO-8859-2?Q?o_tabeli?=
[MSSQL] ACCESS - SQL =?ISO-8859-2?Q?B=B3ad_w_konwersji_lic?==?ISO-8859-2?Q?zb?=
=?iso-8859-2?Q?=5Bmssql=5D_Zapytania_rekurencyjne__-_czy_sk=B3adnia_sql?==?iso-8859-2?Q?_co=B6_takiego_przewiduje_=3F?=
[Oracle PL/SQL] Cursor i zapis =?ISO-8859-2?Q?rekord=F3w_do_?==?ISO-8859-2?Q?kolejnych_plik=F3w?=
=?iso-8859-2?Q?=5BMySQL=5D_Co_minimalnie_potrzebne_zeby_mie=E 6_klienta_My?==?iso-8859-2?Q?SQL_na_Linuxie=3F?=
[newbie] MS SQL - praca =?ISO-8859-2?Q?jednocze=B6nie_na_2_?==?ISO-8859-2?Q?bazach_=28linkowanie_=3F=29?=
[oracle] - Oracle SQL Developer - co to jest SID?
zanotowane.pldoc.pisz.plpdf.pisz.plradioaktywni.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca. Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści Hoc fac - tak czyń. A tergo - od tyłu; z tyłu. I czarne włosy posiwieją. Safona |
|