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?
0
0
Dokąd chcesz przenosić te dane z bazy?
0
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.
0
aby zupdatować schemat danych, muszę zrobić dropa wszystkich tabel [...]
Huh? Ale że niby dlaczego musisz?
0
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,
0
Zdajesz sobie sprawę, że istnieje coś takiego jak alter table, prawda?
0
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.
0
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ć.
0
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.
0
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 consistencyi 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?
0
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.
0
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.