[PostgreSQL] Synchronizacja struktury bazy
Tomek - 06-01-2006 09:03
[PostgreSQL] Synchronizacja struktury bazy
Typowy problem - baza testowa i produkcyjna. Zmienia się struktura na
testowej i trzeba uaktualnić produkcyjną.
Szukałem na grupie, ale nie znalazłem.
Rozwiązanie 1
Robię dump jednego, dump drugiego i używam edytora do porównania obu.
Różnice ręcznie uaktualniam.
Problem: Gdy jedna baza danych jest w wersji 8 a druga 7 to mam kiszkę
(dump z 8 nie wchodzi poprawnie do 7 - różnice składniowe)
Rozwiązanie 2
Logowanie zapytań do bazy
(no właśnie czy jest na to jakiś sposób)
Przecież logowanych jest wiele opcji, trzeba by odfiltrować samego SQLa
BTW dziwię się, że opcji logowania nie ma np. pgAdminIII
Nic prostszego niż zapisywać zmiany zachodzące w strukturze bazy danych
lub samych danych
Rozwiązanie 3
Macie jakieś pomysły?
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 06-01-2006 09:03
Tomek wrote:
> Typowy problem - baza testowa i produkcyjna. Zmienia się struktura na
> testowej i trzeba uaktualnić produkcyjną.
>
> Szukałem na grupie, ale nie znalazłem.
>
> Rozwiązanie 1
> Robię dump jednego, dump drugiego i używam edytora do porównania obu.
> Różnice ręcznie uaktualniam.
>
> Problem: Gdy jedna baza danych jest w wersji 8 a druga 7 to mam kiszkę
> (dump z 8 nie wchodzi poprawnie do 7 - różnice składniowe)
Nie jest to najlepsze rozwiązanie mieć różne bazy.
> Rozwiązanie 2
> Logowanie zapytań do bazy
> (no właśnie czy jest na to jakiś sposób)
> Przecież logowanych jest wiele opcji, trzeba by odfiltrować samego SQLa
>
> BTW dziwię się, że opcji logowania nie ma np. pgAdminIII
> Nic prostszego niż zapisywać zmiany zachodzące w strukturze bazy danych
> lub samych danych
W 8.0 można włąsczyć logowanie samych zapytań ddl - nie testowałem tego.
EMS ma nażędzie, Database Comparer - niestety płatne, ale ma 15 dniowego triala.
Nie jest idealne ale całkiem sprawnie szuka różnic.
--
P.M.
max - 07-01-2006 19:03
Paweł Matejski napisał(a):
> Tomek wrote:
>
>> Typowy problem - baza testowa i produkcyjna. Zmienia się struktura na
>> testowej i trzeba uaktualnić produkcyjną.
>>
>> Szukałem na grupie, ale nie znalazłem.
>>
>> Rozwiązanie 1
>> Robię dump jednego, dump drugiego i używam edytora do porównaniaobu.
>> Różnice ręcznie uaktualniam.
>>
>> Problem: Gdy jedna baza danych jest w wersji 8 a druga 7 to mam kiszkę
>> (dump z 8 nie wchodzi poprawnie do 7 - różnice składniowe)
>
>
> Nie jest to najlepsze rozwiązanie mieć różne bazy.
>
>> Rozwiązanie 2
>> Logowanie zapytań do bazy
>> (no właśnie czy jest na to jakiś sposób)
>> Przecież logowanych jest wiele opcji, trzeba by odfiltrować samegoSQLa
>>
>> BTW dziwię się, że opcji logowania nie ma np. pgAdminIII
>> Nic prostszego niż zapisywać zmiany zachodzące w strukturze bazy
>> danych lub samych danych
>
>
> W 8.0 można włąsczyć logowanie samych zapytań ddl - nie testowałem tego.
>
> EMS ma nażędzie, Database Comparer - niestety płatne, ale ma 15 dniowego
> triala.
>
> Nie jest idealne ale całkiem sprawnie szuka różnic.
>
Najlepiej jest chyba jak w projekcie jest odpowiedzialna jakas osoba za
model bazy danych i tylko ona jest w stanie wykonywac instrukcje
CREATE ....
Update table ...
itp.
a w momecie gdy model jest zmieniany to dotakowo gdzues soobie zapisuje
te instrukcje aby były dla klientów ktorzy maja stare wersje i beda
chieli zaktualizowac.
Jak zarzadzanie nad projektem jest przemyslane gdzies na poczatku drogi
systemu to nie powinno byc problemów .
Gorzej jak pomysły sie pojawiaja gdzies po 4,5 wersji u klienta :)
Max
Lech Bąk - 07-01-2006 19:04
Użytkownik "Tomek" <bazgrusWWWYTTTNIIIJJJJ@yahoo.com> napisał w wiadomości
news:dpk32l$8so$1@atlantis.news.tpi.pl...
> Typowy problem - baza testowa i produkcyjna. Zmienia się struktura na
> testowej i trzeba uaktualnić produkcyjną.
>
[...]
Baza Testowa jest kopią Bazy Produkcyjnej *zanim* zaczniemy testy. Tak więc
wszystko musi być identyczne w momencie 0.
Rozpoczynamy testy nowej wersji systemu.
1. Bierzemy zeszyt i zapisujemy *każdą* zmianę w bazie testowej. Zmiany
powinny być wykonywane za pomocą skryptów tak aby można było wszystko
powtórzyć.
2. Przeprowadzamy testy.
3. Jeśli udane testy to uruchamiamy skrypty na bazie produkcyjnej. Nie
udane, to wszystko kasujemy i kopiujemy bazę produkcyjną do testowej.
4. Czekamy na nową wersję skryptów i ew. systemu
W bezpiecznym miejscu muszą być skrypty tworzące bazę danych oraz
wypełniające wszystkie słowniki. Wówczas nie ma problemu z kopiowaniem bazy
produkcyjnej.
Tak naprawdę to i wersja deweloperska też powinna być postawiona na tym
samym co wersja produkcyjna (system operacyjny, wersja bazy danych, itp)
wtedy mamy mniej problemów.
Pozdrawiam
Leszek
Ronald Kuczek - 09-01-2006 10:09
Użytkownik Tomek napisał:
> Typowy problem - baza testowa i produkcyjna. Zmienia się struktura na
> testowej i trzeba uaktualnić produkcyjną.
>
> Szukałem na grupie, ale nie znalazłem.
>
> Rozwiązanie 1
> Robię dump jednego, dump drugiego i używam edytora do porównania obu.
> Różnice ręcznie uaktualniam.
>
> Problem: Gdy jedna baza danych jest w wersji 8 a druga 7 to mam kiszkę
> (dump z 8 nie wchodzi poprawnie do 7 - różnice składniowe)
>
>
> Rozwiązanie 2
> Logowanie zapytań do bazy
> (no właśnie czy jest na to jakiś sposób)
> Przecież logowanych jest wiele opcji, trzeba by odfiltrować samego SQLa
>
> BTW dziwię się, że opcji logowania nie ma np. pgAdminIII
> Nic prostszego niż zapisywać zmiany zachodzące w strukturze bazy danych
> lub samych danych
>
> Rozwiązanie 3
> Macie jakieś pomysły?
To tylko kwestia dobrego prowadzenia projektu.
Ja robię tak:
1. W tabeli system_version(sysversion text,dbversion
text,requiredcomponentsversion text,appversion text) w polu dbversion
przechowuję string z kolejnym numerem wersji bazy danych.
2. W każdym kolejnym skrypcie z wersji na wersję wywołuję wcześniej
napisaną funkcję plpgsql update_version(numer_wersji text), która:
sprawdza aktualny numer wersji w tabeli system_version. Jeśli wersja <=
żądany_update zwracam błąd "database version same or newer" i kończę, w
przeciwnym wypadku kontunuuję działanie skryptu.
Jasny i prosty mechanizm. W CVS mam skrypty:
DB_CREATE_ver_0.1.0.0.sql
DB_UPDATE_from_0.1.0.0_to_0.2.0.0.sql
DB_UPDATE_from_0.2.0.0_to_0.3.0.0.sql
DB_UPDATE_from_0.3.0.0_to_0.3.0.1_bugs_fixing.sql
DB_UPDATE_from_0.3.0.1_to_0.3.1.0_minor_changes.sq l
DB_UPDATE_from_0.3.1.0_to_0.4.0.0.sql
Do tego np:
DB_DROP_CONSTRAINS_0.1.0.0.sql
DB_CREATE_CONSTRAINS_0.1.0.0.sql
DB_DROP_CONSTRAINS_0.2.0.0.sql
DB_CREATE_CONSTRAINS_0.2.0.0.sql
DB_DROP_INDEXES_0.1.0.0.sql
DB_CREATE_INDEXES_0.1.0.0.sql
DB_DROP_INDEXES_0.2.0.0.sql
DB_CREATE_INDEXES_0.2.0.0.sql
itp. Reszta - w komentarzach do kolejnych rewizji w CVS. Nawet laik może
zrobić update. Szybko, łatwo i przyjemnie - wymaga jedynie pewnej
dyscypliny. Przeglądając skrypty można błyskawicznie stwierdzić co
zmieniło się z wersji na wersję i ewentualnie dlaczego coś nie działa
(bo doszła tabela, funkcja, pole itp.).
Pozdrawiam
Rony
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?=
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
[postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?=
[postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?=
[PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?=
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Problemy z =?ISO-8859-2?Q?instalacj=B1_PostgreSQL_na_syste?==?ISO-8859-2?Q?mach_Windows?=
zanotowane.pldoc.pisz.plpdf.pisz.plmorebeer.opx.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 |
|
