ďťż
 
[SQL server] Polaczenie miedzy bazami? ďťż
 
[SQL server] Polaczenie miedzy bazami?
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

[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.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    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.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • radioaktywni.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

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com