MySQL: kopiowanie pola

Mam bazy danych lokalnie, oraz na serwerze. Zdarza się dość często, że w lokalnej bazie następują zmiany, np, zostanie dodane pole (field) i następnie trzeba to samo pole dodać do bazy, która jest na serwerze.

Moje pytanie brzmi: jak to zrobić szybko? Oczywiście mogę przyjrzeć się bazie lokalnie i dodać takie same pole na serwerze, ale gdy trzeba to robić wielokrotnie to po pierwsze się nie chce, a po drugie można popełnić głupi błąd przy kopiowaniu. Czy jest jakiś sposób aby wyeksportować dodanie jednego pola?

Aby to jeszcze lepiej wyjaśnić, czy da się wyeksportować komendę typu:

ALTER TABLE  `tbl` ADD  `new` VARCHAR( 2 ) NOT NULL DEFAULT  'en';

wykonując to na serwerze miałbym dokładnie taką samą zmianę jak lokalnie.

2 lata, 3 miesiące temu | edytowane przez: Bilberry 4462524

Odpowiedz na pytanie

2

Odpowiedzi: 5

  • 2 lata, 3 miesiące temu
    autor: michu

    3

    O ile dobrze zrozumiałem, pytanie jest raczej o zmiany w strukturze tabel, a nie o samą replikację danych.

    Tak naprawdę to jest szerszy temat, określany czasem jako zarządzanie konfiguracją (configuration management) - proces którego zadaniem jest utrzymanie spójności systemu w całym jego cyklu życia. W takim najbardziej rozbudowanym zakresie to jest ściśle okreslony proces, składający się ze zdefiniowanych procedur, środowisk testowych itd. Ale nie o tym tutaj, więc tylko sygnalizuję i zachęcam, żeby sobie poczytać.

    Odpowiadając na samo pytanie - ja tego typu rzeczy robię w ten sposób, że każda zmiana na bazie danych jest opisana skryptem SQL. Nieważne czy zaczynam od skryptu pisanego "z palca", czy jest on tworzony za pomocą narzędzia do porównywania struktury baz danych - każda zmiana wersji w moim środowisku programistycznym powoduje powstanie skryptu. Skrypty te zawierają nie tylko instrukcje manipulujące strukturą tabel, ale też np. odpowiednie polecenia update czy insert, które dopasowują w razie potrzeby dane do nowej struktury, czy wypełniają nowo dodane słowniki, itd.

    Taki skrypt ma w nazwie numer wersji, tak zapisany z dopełnieniem zerami, żeby domyślne sortowanie systemu operacyjnego powodowało uporządkowanie w odpowiedniej kolejności (to się przydaje jak musi to przeglądać żywa osoba). Podniesienie bazy danych w środowisku testowym lub produkcyjnym sprowadza się wówczas do wykonania przygotowanych skryptów w kolejności numeracji.

    Do tego dochodzi zapisanie numeru wersji w bazie danych w oddzielnej tabeli - gdy wgrywam nową wersję aplikacji, to porównuje ona wersję bazy danych ze swoją aktualną wersją i automatycznie wykonuje te skrypty wprowadzające niezbędne zmiany.

    Wraz z aktualizacją aplikacji dystrybuuję zawsze wszystkie skrypty przyrostowe począwszy od początkowej wersji bazy danych. To pozwala na aktualizację do najnowszej wersji niezależnie od tego, w jakim stanie, w jakiej wersji znajduje się aktualizowane środowisko.

  • 2 lata, 3 miesiące temu
    autor: Novakov

    2

    Problem z wersjonowaniem schemtu bazy danych jest duży i jak narazie jedyne wygodne rozwiązanie jakie znam to pisanie skryptów opisujących każdą zmianę w bazie (tak robi np/ Ruby on Rails). Dzieki temu mozna łatwo aktualizować bazy danych.

    Jesli chodzi o jakies proste i szybkie rozwiązanie to przychodzi mi do głowy coś takiego:

    • Wygenerować instrukcję create dla tabeli w lokalnej bazie

    mysqldump --skip-opt --compact --no-data baza tabela > local.sql

    • To samo dla zdalnej bazy

    mysqldump -hvery_important_server --skip-opt --compact --no-data baza tabela > remote.sql

    • Potem można porównać te dwa zrzuty, np. poleceniem diff

    Może nie jest to jakieś super wygodne rozwiązanie, ale już nie tak łatwo pominac jakieś pole, a do instrukcji alert można wkleić definicję pola. Zapewne da się do jeszcze jakość oskrypcić i będzie działało samo

  • 2 lata, 3 miesiące temu
    autor: Manveru

    1

    Systemy silników baz danych posiadają mechanizmy replikacji. W MySQL sprawa jest ciężka... choć możliwa mniej lub bardziej.

    Polecam lekturę: MySQL Manual + komentarze użytkowników. Trzeba poćwiczyć. Jest też ponoć silnik wspierający replikację na poziomie transakcji, ale szczegółów nie znam.

    Artykuł Advanced MySQL replication jest też cholernie interesujący, zawsze się zastanawiałem, czy coś takiego się da zrobić i okazuje się, że się da!

  • 2 lata, 3 miesiące temu
    edytowane przez: lqc
    Pytanie społeczności

    0

    Jeśli często ci się zdarza, że musisz zmieniać schemat, to zastanowiłbym się czy twój model danych jest dobry. Ogólnie schemat powinien zmieniać się rzadko.

    To co chcesz robić to migracja schematu i rady micha są tu bardzo użyteczne.

  • 2 lata, 2 miesiące temu
    autor: pmadry

    0

    Z Twojego pytania nie wynika, czy dopiero tworzysz aplikację czy to już eksploatacja?
    Każdy z tych etapów rządzi się innymi rygorami...

Zaloguj się, aby dodać swoją odpowiedź