Dlaczego i kiedy Liquibase?

98

Próbowałem przeszukać to pytanie w przypadku przepełnienia stosu, ale nie mogłem znaleźć żadnego pytania.
Jestem nowy Liquibasei chcę wiedzieć

Dlaczego Liquibase?
Kiedy dokładnie należy użyć Liquibasew projekcie?

Wiem, że ma to na celu utrzymanie wszystkich zmian w bazie danych w jednym miejscu, ale podobnie można zrobić, tworząc proste SQLpliki w jakimś systemie repozytoriów i aktualizując je z czasem.

database liquibase

— Shakeel Shahzad
źródło

70

Kluczową różnicą między samodzielnie zarządzanym plikiem tworzenia schematu a Liquibase (lub innymi narzędziami do migracji schematu ) jest to, że ten ostatni udostępnia dziennik zmian schematu. To jest zapis zmian schematu w czasie. Pozwala projektantowi bazy danych na określenie zmian w schemacie i umożliwia programową aktualizację lub downgrade schematu na żądanie.

Istnieją inne korzyści, takie jak:

Niezależność dostawcy bazy danych (jest to wątpliwe, ale próbują)
zautomatyzowana dokumentacja
różnice w schemacie bazy danych

Jednym z alternatywnych narzędzi jest flyway .

Możesz zdecydować się na użycie narzędzia do migracji schematu, gdy chcesz lub musisz automatycznie zarządzać aktualizacjami schematu bez utraty danych. Oznacza to, że po wdrożeniu systemu w długotrwałym środowisku, takim jak lokacja klienta lub stabilne środowisko testowe, spodziewasz się zmiany schematu.

— Synesso
źródło

1

Ale załóżmy, że tworzymy plik, piszemy w nim nasz pierwszy skrypt i zatwierdzamy go do, powiedzmy, git. Teraz, wraz z upływem czasu, schemat zostanie zaktualizowany i będziemy mogli cofnąć się do dowolnego przedziału czasu i ponownie zmienić schemat, nie?

— Shakeel Shahzad

1

Dzięki takiemu podejściu możesz odtworzyć schemat, ale nie możesz obniżyć / uaktualnić. Różnica polega na utracie danych.

— Synesso

1

Ale brakuje drugiej części, kiedy użyć?

— Shakeel Shahzad

1

Synesso Nie wiem jeszcze, jak można automatycznie obniżyć wersję produkcyjnej bazy danych po jej używaniu przez jakiś czas i podjęciu decyzji dotyczących danych przy użyciu, powiedzmy, nowo dodanych kolumn. Nie możesz ich teraz po prostu upuścić. Nie rozumiem też, dlaczego jest to lepsze niż tylko seria wersjonowanych skryptów SQL przechowywanych w kontroli źródła, które zawierają prostą wstawkę do tabeli wersji na początku i aktualizację na końcu, aby śledzić, co zostało zastosowane.

— Khorkrak

Kolejne pytanie dodające ... jak możemy zarejestrować błąd przez e-mail w java. kiedy zmiany SQL zmieniają się poprzez XML?

— UmaShankar

18

Widziałem, jak liquibase tworzy dyscyplinę wśród programistów, jeśli chodzi o modyfikowanie schematu. Po prostu nie możesz przejść i nadpisać zmiany i wykonania innego programisty. Zamiast tego tworzysz swój własny zestaw zmian i dodajesz go na końcu sekwencji zmian do wykonania. Daje to również jasność co do tego, jaka zmiana nastąpiła, kiedy i kto ją przyniósł.

Bardzo "wersjonowane" podejście do utrzymania schematu.

Na początek jednak sprawia wrażenie „niepotrzebnej pracy”.

— iCrus
źródło

4

Który to ja (daje mi to dokładne wrażenie, o którym wspomniałeś: P) +1 za tę kluczową determinację

— Ismail Sahin

masz rację, możemy śledzić wszystkie zmiany, które wprowadziły ostatnie zmiany i kiedy. gdybyśmy chcieli wrócić do konkretnego punktu, cieczibase będzie pomocna

— Anoop PS

7

Jeśli masz wiele instancji bazy danych w dev, qa, production i chcesz mieć narzędzie do automatycznego śledzenia historii zmian i inteligentnego wprowadzania zmian (zastosuj różnicę bieżącego schematu i ostatecznego schematu), narzędzia takie jak liquibase lub flyway będą bardzo przydatne .

— Ted Xu
źródło

3

Uważam, że Liquibase jest świetny, gdy Twoja filozofia polega na tym, że baza danych jest po namyśle. Ta filozofia spowodowała, że większość złych baz danych jest w produkcji - a większość z nich jest zła. Baza danych powinna być zaprojektowana z pełnym widokiem całego systemu biznesowego, a nie tworzona przez programistów aplikacji pracujących we własnych silosach. Ta ostatnia metoda prowadzi do obejść, zdenormalizowanych danych, słabych relacji między tabelami, powielania obszarów biznesowych i ogólnie niechlujnego systemu o wysokich kosztach utrzymania, którego klient będzie nienawidził wkrótce po wdrożeniu z powodu problemów, które powoduje. Jeśli baza danych jest zaprojektowana tak, aby DOKŁADNIE odzwierciedlała relacje biznesowe, jej żywotność będzie 5 razy dłuższa i będzie służyć swojemu celowi 5 razy lepiej niż baza danych zaprojektowana w sposób fragmentaryczny, jak niestety większość.

Liquibase nie jest problemem sam w sobie, ale umożliwia praktykę, w której programiści aplikacji projektują bazę danych. To jest problem.

— Bob Barry
źródło

19

Zmieniają się specyfikacje, dodawane są nowe funkcje, naprawiane są błędy. Nawet zakładając, że „baza danych została zaprojektowana tak, aby DOKŁADNIE odzwierciedlała relacje biznesowe”, jest to normalne i oczekuje się, że z czasem będziesz musiał wprowadzać zmiany w bazie danych, ponieważ firmy i relacje biznesowe zmieniają się w czasie. Liquibase po prostu pomaga zarządzać tymi zmianami. Otóż to.

— Steven Byks

Z mojego doświadczenia wynika, że bardzo niewielu administratorów baz danych i cała rzesza programistów używa Liquibase - myślę, że @ bob-barry jest na miejscu w większości wyników końcowych. Administratorzy baz danych, którzy używają narzędzi takich jak Liquibase (lub po prostu stary git do historii zmian) uznają to za przydatne.

— PhillipHolmes

Ewolucyjne praktyki baz danych i ogólnie zwinność zachęcają i umożliwiają wzajemne oceny. W przypadku bazy danych wymagającej wydajności administratorzy baz danych nadal współpracują z zespołami aplikacji w celu wprowadzenia zmian w bazie danych. Narzędzia takie jak Liquibase umożliwiają łatwiejszą refaktoryzację, sprzeczną z argumentem denormalizacyjnym. 10 lat temu pracowałem nad produktem zainstalowanym na ponad 20 klientach, z których każdy miał własne cykle poprawek i uaktualnień. Po 2 latach koszmaru i próbie ręcznego napisania takiego narzędzia, jak tylko się o tym dowiedzieliśmy, wskoczyliśmy do liquibase. Mieliśmy stoły z 200 milionami rekordów, też nie były duże jak na tamten czas, ale coś wymagało administratorów baz danych.

— user6317694

3

Mam nadzieję, że spotkamy się kiedyś w niebie. Jasne, brzmi nieźle.

— Bijan

3

Myślę, że można odpowiedzieć na pytanie, dlaczego liquidibase przeczytasz w poniższym artykule http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

Jeśli uważnie ją przeczytasz, możliwość przejścia na niższą wersję z wyższej wersji za pomocą prostych poleceń mvn lub CLI jest bardzo przydatna, czego nie otrzymasz, jeśli przejdziesz przez podejście polegające na zatwierdzeniu pliku sql do GIT, ponieważ wtedy musisz ręcznie uruchamiać te skrypty, a także nie masz zestawu zmian, takich jak: - kto wprowadził zmiany, autor itp.

— Shikhar Chaudhary
źródło

0

Będąc osobą DevOps w moim zespole, wolałbym mieć wszystkie moje pliki SQL w jednym miejscu, tj. W moim SCM (Source Code Management)

Również podczas CI fazy / CD, jeśli schemat bazy danych zostanie utworzony wraz z nim, oszczędza to dużo czasu i zasobów. Nie musiałbyś mieć innej osoby zarządzającej bazą danych dla tego klienta.

ORM, takie jak Flyway, Liquibase, EF itp., Pomaga w osiągnięciu tego.

— Sloka Roy
źródło