w tym samym czasie Git stał się popularny, a trend pisania aplikacji internetowych przy użyciu bibliotek mapowania obiektowo-relacyjnego (ORM) również stał się znany. Kluczową ideą było to: ponieważ programiści mogą wprowadzać zmiany w kodzie, które są łatwe do cofnięcia za pomocą Git, dlaczego programiści nie mogą zrobić tego samego, jeśli chodzi o zmiany schematu? W końcu każda rozsądna nowa funkcja wiąże się ze zmianami w kodzie i schemacie. Tak popularne frameworki jak Rails i Django dodały migrację ORM i bazy danych (znaną również jako migracja schematów) jako część swojej oferty. Ale migracja baz danych jako koncepcja nie ogranicza się do popularnych frameworków internetowych. Istnieją nawet samodzielne biblioteki oprogramowania do migracji baz danych, takie jak Flyway i Liquibase. Czy możesz sobie wyobrazić, że jest w stanie cofnąć ziarniste zmiany w schemacie podczas pisania kodu? Zbyt często stwierdzam, że artykuły na temat migracji baz danych nie omawiają, co to znaczy aktywnie robić, jako programista. Chcę to poprawić. Mając to na uwadze, dzisiaj przedstawię wam całościowy obraz tego, na czym polega migracja baz danych i jak to zrobić w aktywnym środowisku programistycznym. Podzielę to na trzy części, obejmujące to, co dzieje się podczas procesu migracji, typowe używane Narzędzia i pułapki, które mogą pojawić się podczas migracji bazy danych. Powinno to dać początkującym programistom narzędzia do szybkiego poznania kluczowych pomysłów stojących za migracją danych, a także poznać potencjalne pułapki, których należy unikać podczas korzystania z migracji bazy danych jako części jego zestawu narzędzi programistycznych.
Co Się Dzieje Podczas Migracji Bazy Danych?
teraz, kiedy wiesz, jak doszło do migracji baz danych, pozwól, że przedstawię ci, co faktycznie się z nimi wiąże.
szczegółowe zmiany są generowane jako pojedyncze pliki Skryptowe
wspomniałem, jak migracje baz danych zasadniczo śledzą szczegółowe zmiany w schemacie bazy danych (a czasami także w danych). Te szczegółowe zmiany są zwykle odzwierciedlane jako oddzielne pliki skryptów. W ten sposób szczegółowe zmiany schematu są odzwierciedlane jako kod, który można przechwycić za pomocą dowolnego oprogramowania do kontroli wersji. To jest przykład pliku migracyjnego w Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
migracje mogą być nie tylko samodzielnymi plikami, ale również bieżącym schematem bazy danych jako własnym plikiem. Zazwyczaj jest to znany jako plik schematu.
Skrypty migracji bazy danych są zależne od narzędzi
Przypomnij skrypt migracji bazy danych w Ruby z naszego wcześniejszego przykładu. Oto kolejny plik migracji bazy danych z niezależnej kontroli źródła dla oprogramowania bazodanowego Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
tym razem plik jest w formacie XML. W rzeczywistości Liquibase może tworzyć zmiany migracji (lub zestawy zmian, jak je lubią nazywać) w wielu formatach, takich jak XML i JSON. Jeśli więc nie chcesz ręcznie zapisywać migracji bazy danych w formacie SQL, nie ma prawdziwych standardów dotyczących tworzenia plików migracji. Oczywiście możesz napisać własne niestandardowe skrypty migracji bazy danych w plikach SQL. Ale po co odręcznie i przypadkowo wprowadzać błędy, skoro można korzystać z narzędzi do automatycznego generowania migracji bazy danych?
jak przeprowadzić migrację bazy danych?
teraz wiesz, co to jest migracja bazy danych. Musisz również wiedzieć (przynajmniej koncepcyjnie), jak przeprowadzić migrację bazy danych. Niestety, nie ma żadnych standardów dla plików migracji bazy danych, co oznacza, że nie możemy uzyskać zbyt wiele szczegółów na temat ich tworzenia. Innymi słowy, sposób migracji bazy danych zależy w dużej mierze od konkretnego narzędzia, którego używasz do wykonania zadania. W tej sekcji omówię dwa najczęstsze sposoby migracji bazy danych.
Opcja 1: Użyj Biblioteki zależnej od frameworka/języka
, jeśli używasz popularnego języka (Ruby, PHP, Python itp.) lub framework (Rails, Django, itd.), następnie istnieją dobrze udokumentowane biblioteki do migracji danych we wszechświecie wybranego frameworka/języka. Popularne frameworki internetowe będą naturalnie dostarczane w pakiecie z funkcjami migracji bazy danych. W zależności od konfiguracji można nawet zamienić natywną migrację bazy danych na inne biblioteki w wybranym języku. Zazwyczaj w tym scenariuszu pliki migracji są generowane za pomocą wiersza poleceń. Czasami może być konieczne ręczne przepisanie kodu niestandardowego w przypadku niektórych zmian, takich jak migracja danych lub nawet odwrócenie samej zmiany. Poza tym biblioteka wybrana w ramach / języku dba o to za Ciebie.
Opcja 2: Użyj niezależnego oprogramowania skoncentrowanego na migracji bazy danych
w niektórych przypadkach będziesz chciał użyć oprogramowania takiego jak Flyway lub Liquibase, które po prostu działa jako Kontrola źródła dla twojej bazy danych. W ten sposób unikasz zamknięcia się w określonym frameworku lub języku. Nie oznacza to, że masz zero blokady. Weźmy na przykład Flyway, który działa dobrze z różnymi bazami danych, takimi jak Oracle, MySQL i MariaDB. Jeśli nie korzystasz z migracji opartej na Javie Flyway (która blokuje cię w Javie i Flyway), możesz skorzystać z migracji opartej na SQL (która blokuje cię do wybranej bazy danych i Flyway). Dobrą wiadomością jest to, że Flyway i Liquibase są stosunkowo łatwe w użyciu. Zapewniają one również sposób generowania migracji w wierszu poleceń i umożliwiają niestandardowe kodowanie w celu przechwycenia migracji schematu bazy danych.
wybór najlepszej opcji dla Ciebie
oto moja opinia na temat wyboru jednej z opcji. Większość programistów wybiera opcję 1. Zwykle dzieje się tak dlatego, że programiści mają już preferowany język/framework, więc mówiąc poznawczo, nie ma wrażenia, że uczą się (jeszcze) innego oprogramowania. A zamknięcie (w przypadku wariantu 1 byłoby to związane z ramami i językiem) jest całkowicie dobrowolne i pożądane. Możesz uzasadnić opcję 2, jeśli twój zespół nie jest w pełni zaangażowany w określony język lub ramy. Niezależnie od tego, co wybierzesz, unikaj niepotrzebnej zmiany wyboru w połowie rozwoju. Migracja bazy danych nie jest obszarem, w którym zmiana narzędzi przynosi ogromne korzyści. Większość korzyści wynika z prostej konfiguracji migracji bazy danych.
zagrożenia związane z migracją baz danych i jak ich uniknąć
w poprzedniej sekcji omówiłem dwa główne typy narzędzi do migracji baz danych: zależne od struktury/języka i samodzielne oprogramowanie. Oba typy są łatwe w użyciu. Teraz polecam trzy najlepsze praktyki, jeśli chodzi o przeprowadzanie migracji bazy danych. Te wskazówki dotyczą głównego zagrożenia związanego z migracją bazy danych: chcesz uniknąć nieodwracalnych zmian.
wybierz jedno narzędzie do migracji bazy danych i trzymaj się go
wspomniałem o tym krótko wcześniej, ale warto to podkreślić: chcę ostrzec przed niepotrzebnymi zmianami w zestawie narzędzi po prostu dlatego, że jest fajny. Przypomnijmy, że skrypty migracji bazy danych zależą od narzędzia, którego używasz do ich generowania. Nie ma odpowiednich standardów dla tych skryptów. Jeśli naprawdę chcesz, możesz nawet napisać własne w poleceniach SQL. Wprowadza to własny zestaw problemów; na przykład Twoje skrypty SQL mogą być zależne od bazy danych. Zapytania MySQL mogą nie działać w PostgreSQL i odwrotnie. Więc albo jesteś zablokowany w narzędziu do migracji bazy danych, albo jesteś zablokowany w wybranej bazie danych-lub w niektórych przypadkach, nawet obu. Nie ma oczywistych korzyści z częstego przełączania zestawu narzędzi, więc proponuję wybrać jedno narzędzie do migracji bazy danych i trzymać się go. Są lepsze rzeczy do zrobienia z Twoim czasem niż niepotrzebnie kręcić kołami.
Usuń wiersze lub kolumny tylko wtedy, gdy masz absolutną pewność, że musisz
jeśli chodzi o migracje, w większości przypadków możesz je odwrócić, gdy zajdzie taka potrzeba. Typowe narzędzia migracji bazy danych mogą obsługiwać proste odwracalne zmiany. A nawet jeśli nie mogą, możesz łatwo dodać własny niestandardowy kod, aby pomóc w cofaniu. Na przykład w Rails po prostu dodajesz kod pod odwracalny.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
najtrudniejsze zmiany do odwrócenia mają tendencję do usuwania rzeczy: w szczególności usuwania kolumn lub wierszy danych. Jeśli baza danych zawiera dużo danych, może się okazać, że będziesz musiał napisać znaczną ilość kodu niestandardowego, aby spróbować odwrócić zmiany. Jeśli więc rozważasz usunięcie danych z bazy danych, zachowaj szczególną ostrożność. Tego typu zmiany trudno cofnąć. Inne trudne do odwrócenia zmiany obejmują zmianę nazw kolumn i zmianę typu danych kolumny, która już zawiera dane. Jedną z reguł, którą lubię stosować, jest ta: prawie nigdy nie należy usuwać kolumn do następnego major (znasz semver, prawda?) release. Ta reguła ma zastosowanie nawet jeśli mam kolumny, których chcę przestać używać. Zamiast usuwać kolumny, ogłoszę w mniejszych wersjach, które kolumny będą przestarzałe w przyszłości. Kiedy przyjdzie czas na Główne wydanie, porzucę te kolumny całkowicie. W ten sposób zmniejszam szanse na dokonanie przypadkowej, niechcianej zmiany, która będzie okropnym procesem do odwrócenia ręcznie.
zaimplementuj flagi funkcji
kolejną doskonałą strategią migracji baz danych jest implementacja FLAG funkcji, zwłaszcza gdy masz duży zespół i wiele osób próbuje zaimplementować różne funkcje dla tego samego kodu. Według Martina Fowlera flagi funkcji są ” potężną techniką, pozwalającą zespołom modyfikować zachowanie systemu bez zmiany kodu.”W rzeczywistości, im większy jest Twój zespół i bardziej skomplikowana jest baza kodu, tym więcej flag funkcji świeci. Flagi funkcji pomagają zmniejszyć ryzyko migracji baz danych. Próba rozwikłania zmian, gdy trzeba cofnąć niektóre funkcje, może być prawdziwym koszmarem. Flagi funkcji działają równie dobrze, niezależnie od tego, czy chcesz wprowadzić małe, czy duże zmiany schematu bazy danych. Podczas korzystania z FLAG funkcji, polecam dążyć do częstszych i bardziej szczegółowych zmian ogólnie. I naprawdę można zobaczyć, jak flagi funkcji pomóc proces rozwoju podczas wykonywania ogromny schemat zmiany. Proszę nadal dążyć do złamania tego masywnego schematu zmiany na mniejsze, cienkie plasterki. Nie musisz nikomu imponować tym, ile możesz wcisnąć w jedną zmianę. Lepiej dodać zabezpieczenia do praktyk programistycznych, wdrażając wszystkie trzy zalecenia, o których mówiłem w tej sekcji.
podsumowanie
programiści potrzebują wszystkich narzędzi, które mogą uzyskać, aby ułatwić sobie życie. Migracja bazy danych jest jednym z tych niezbędnych narzędzi dla programisty. W przyszłości przewiduję, że migracje baz danych będą ewoluować od najlepszych praktyk programistycznych do standardowych praktyk programistycznych. Ludzie będą patrzeć na Ciebie zabawnie za to, że w ogóle nie korzystasz z migracji bazy danych. Jednak ważne jest, aby pamiętać, w jaki sposób migracje baz danych mogą powodować awarie, szczególnie w przypadku trudnych do odwrócenia zmian schematu. Bądź absolutnie pewien tych zmian, zanim je uruchomisz. Jeśli nie korzystasz jeszcze z migracji bazy danych w swoim procesie, Na co czekasz? Jest to łatwe do rozpoczęcia, a nawet można dodać go w połowie cyklu rozwoju. Będziesz wdzięczny, że to zrobiłeś. Ponieważ kiedy nadejdzie dzień, w którym będziesz musiał wycofać swoje zmiany, a zmiany dotyczą bazy danych, będziesz żałować, że nie masz czegoś, co pomoże Ci to zrobić w zaledwie kilka sekund. Migracja bazy danych to coś, czego chciałbyś mieć.