Hej, czy dobrym pomysłem będzie w mechanizmie do updatu schematu bazy danych przenoszenie także wszystkich danych zawartych w bazie?
Myślę że takie coś może znacznie obciążyć system, zwłaszcza wtedy gdy w bazie będzie dużo rekordów. Mogę się oczywiście mylić i jest jakiś dobry/optymalny sposób na dodanie takiej funkcjonalności?
Dokąd chcesz przenosić te dane z bazy?
Do tej samej bazy. Chodzi o to że aby zupdatować schemat danych, muszę zrobić dropa wszystkich tabel i utworzyć je na nowo, wtedy nowy schemat jest pusty, bez tych danych, które wcześniej w niej były.
PS: NIE ZROBIŁEM DROPA NA PRODUKCJI.
aby zupdatować schemat danych, muszę zrobić dropa wszystkich tabel [...]
Huh? Ale że niby dlaczego musisz?
Patryk27 napisał(a):
aby zupdatować schemat danych, muszę zrobić dropa wszystkich tabel [...]
Huh? Ale że niby dlaczego musisz?
Wykonuje to w ten sposób że po prostu robię "CREATE TABLE nazwa tabeli" później nazwy tabel i ich właściwości. Jeśli takowa tabela jest w bazie danych, wyskakuje błąd z tym związany. Dlatego takiej tabeli nie może być w bazie danych,
Zdajesz sobie sprawę, że istnieje coś takiego jak alter table
, prawda?
Mistrzowski Szewc napisał(a):
Patryk27 napisał(a):
aby zupdatować schemat danych, muszę zrobić dropa wszystkich tabel [...]
Huh? Ale że niby dlaczego musisz?
Wykonuje to w ten sposób że po prostu robię "CREATE TABLE nazwa tabeli" później nazwy tabel i ich właściwości. Jeśli takowa tabela jest w bazie danych, wyskakuje błąd z tym związany. Dlatego takiej tabeli nie może być w bazie danych,
Chętnie przyjmę pomysły jak można zrobić to lepiej.
Patryk27 napisał(a):
Zdajesz sobie sprawę, że istnieje coś takiego jak
alter table
, prawda?
Tak, jednakże plik sql powinien być jak najbardziej prosty, czyli jak ktoś doda sobie kolumnę w CREATE TABLE to system musi to już łapać.
Widzisz - sam sobie rzucasz kłody pod nogi :-)
Wyobraź sobie, że masz tabelę z milionem produktów (co w zasadzie nie jest wcale tak dużą liczbą) i teraz odpalasz na tym drop
+ create table
:
- Baza danych musi faktycznie usunąć z dysku wszystkie dane po tabeli, po czym znowu je utworzyć, czyli marnujesz zasoby (dysk + czas). Powodzenia ze zrobieniem w sensownym czasie miliona insertów, jeśli tabela ma indeksy oraz constrainty.
- Jak sam zauważyłeś, występuje problem z przeniesieniem danych ze starej wersji do nowej.
Rozwiązanie jest proste: alter table
.
czyli jak ktoś doda sobie kolumnę w CREATE TABLE to system musi to już łapać.
Każda nowa migracja powinna być odrębnym plikiem - wtedy możesz bez problemu robić alter table
, nie musisz martwić się o data consistency
i ogólnie to wszystko śmiga.
Patryk27 napisał(a):
Widzisz - sam sobie rzucasz kłody pod nogi :-)
Wyobraź sobie, że masz tabelę z milionem produktów (co w zasadzie nie jest wcale tak dużą liczbą) i teraz odpalasz na tym
drop
+create table
:
- Baza danych musi faktycznie usunąć z dysku wszystkie dane po tabeli, po czym znowu je utworzyć, czyli marnujesz zasoby (dysk + czas). Powodzenia ze zrobieniem w sensownym czasie miliona insertów, jeśli tabela ma indeksy oraz constrainty.
- Jak sam zauważyłeś, występuje problem z przeniesieniem danych ze starej wersji do nowej.
Rozwiązanie jest proste:
alter table
.czyli jak ktoś doda sobie kolumnę w CREATE TABLE to system musi to już łapać.
Każda nowa migracja powinna być odrębnym plikiem - wtedy możesz bez problemu robić
alter table
, nie musisz martwić się odata consistency
i ogólnie to wszystko śmiga.
W tym przypadku musaiłbym porównywać poszczególne migracje ? wyodrębniać poszczególne kolumny i sprawdzać w której jakiej nie ma i na tej podstawie generować sql z alter table?
Albo tak, albo zwyczajnie rozkaż użytkownikom, aby sami tworzyli migracje - narzędzie do diffowania baz będziesz tworzył kilka tygodni, a napisanie takiej migracji ręcznie to przecież minuta.
Patryk27 napisał(a):
Albo tak, albo zwyczajnie rozkaż użytkownikom, aby sami tworzyli migracje - narzędzie do diffowania baz będziesz tworzył kilka tygodni, a napisanie takiej migracji ręcznie to przecież minuta.
Masz rację, dziękuję za cenne wskazówki.