Verzování změn struktury databáse
- ZETCHA
- Člen | 59
Měl bych dotaz.
Před časem jsem na pár měsíců zavítal do vod Ruby a Ruby on Rails.
Po návratu do světa PHP mi chybí jedna šikovná věc při vývoji ve
větším týmu a nasazování jednotlivých změn na web.
Jedná se o verzování změn v DB tzv. migrace. Hledal jsem na webu nějaké šikovné a přitom jednoduché řešení pro PHP. Zatím jsme neuspěl. Máte někdo s tímto zkušenosti popřípadě nějaké dostupné řešení?
Ideál je samozřejmě ukládání jednotlivých změn do dokumentů v rámci projektu a jejich obsluha např. z příkazové řádky (tak jako v Railsech). Výhoda je zřejmá – možnost verzovat dokumenty v SVN, GIT, … a zautomatizovat provedení změn v instal. scriptu.
Dík za Vaše zkušenosti.
- Mikulas Dite
- Člen | 756
Jde udržovat nějaký soubor s sql pro vytvořením tabulek (případně i databáze). Dobře se to verzuje a deploy je taky hračka. Jediný problém je občas v přenášení dat mezi původní a novou verzí, to se ale moc vyřešit nedá.
- ZETCHA
- Člen | 59
To samozřejmě jde, ale je to dosti nepřehledné (hlavně u aplikací s velkým množstvím tabulek).
Preferoval bych jednotlivá změna = jeden soubor. V DB by byla tabulka ve které je zapsaná verze stavu DB. Z příkazové řádky spustit všechny aktualizace DB nebo jen jednotlivé, popřípadě mít možnost vrátit se k předchozí verzi. Pak by šlo i zautomatizovat upozornění, že po updatu z SVN je zapotřebí udělat migrace.
- Mikulas Dite
- Člen | 756
Mít všechny soubory není potřeba, protože se to přeci verzuje. Situace, že se vrátí db a ne kód nestojí za složité workflow.
S nepřehledností více méně souhlasím, ale i pár desítek
CREATE TABLE je docela čitelné. Navíc se z toho dá snadno
generovat UML, což jednotlivé ALTER TABLE v různých souborech
nedokážou zdaleka tak dobře.
- ZETCHA
- Člen | 59
Hmm, nevím jestli ti teď rozumím. Pokud budu udržovat jeden soubor ve kterém budu mít definici všech tabulek a budu ho verzovat tak mi to neřeší případy změn v DB. Nechci mazat a znovu vytvářet novou strukturu.
Potřebuji právě jen ten jednotlivý alter. Mohu to přidávat do toho souboru, ale bojím se, že u větších a dlouhodobě vyvíjených projektů se časem začneme ztrácet.
Nemluvě o případech kdy se do toho jednoho souboru přidá úprava DB (dokud si ji pamatuji) související s ještě nedokončenými úpravami kódu a aplikace po migraci DB přestane fungovat.
V případě jednotlivých souborů kde by byli nadefinovány akce pro upgrade i downgrade DB by to znamenalo couvnout v migraci zpět a hotovo (samozřejmě mimo případů ztrát dat), ale pokud dobře chápu tvůj návrh – bylo by s tím více práce.
Co se týká UML – nedokážu posoudit. Jsem ním zatím nedotčen.
- Filip Procházka
- Moderator | 4668
Nebudeš se ztrácet, je to prosté. Stačí si udělat na začátku souboru „counter“
1234_feature_kratky_popis_upravy.sql
Funguje to. A pokud potřebuju nějaké UML, tak si buďto zobrazím strukturu v Admineru, nebo si aktuální sql struktury vygeneruju :)
A vůbec se neboj toho, že tam dáš strukturu i aktualizace dat na převod na novou strukturu. Je to aspoň hezky pohromadě a ví se co se tou aktualizací má změnit/změnilo.
- BigCharlie
- Člen | 283
Myslím, že hledáš tohle. Koneckonců je to importováno z Ruby. Pokud se nepletu, pracuje/pracoval s tím Jirka Knesl, ten by s tím mohl mít víc zkušeností.
- mcmatak
- Člen | 504
down mi prijde nerealny, ve vetsine pripadu to skoro nejde snad pouzit ja pouzivam uplne jednoduchy skript, vsechny zmeny ukladam v souborech se zvysujicim cislem v nazvu, v databazi je tabulka ktera udrzuje aktualni verzi, skript pak zjistit jeslti existuji soubory s vyssim cislem verze a ty proste importuje do databáze, skript má asi 10 řádků … down bohužel neřeším