Ake nastroje a postupy pouzivate na vyvoj a udrziavanie databazovych projektov, najma ak databaza je uz v produkcii?
SQL Management Studio + ukladanie change scriptov ma nevyhodu, ze update ide iba jednyn smerom a hoci je vyvoch super jednoduchy, vsetko ostatne je uz tazkopadne. V minulosti som to skombinoval zo skvelym nastrojom SQL Delta, ktory vizualne prezentoval zmeny v scheme aj datach a vygenerovat migracne skripty.
Entity Framework Core Migrations funguje celkom fajn, ale iba pri Code First. Vacsinu limitacii sa mi podarilo obist jednoduchym skriptom, ktory som spusal vzdy pred, alebo po migracii. Napriklad zapnutie fulltext search. Na existujuce projekty to ale nieje v ziadnom pripade cesta.
Visual Studio Database Project je super, ale nikdy sa mi nepodarilo spravit schopny automatizovany deployment.
Chcelo by to nejaky podobny nastroj ako Database Project, ale s migraciami namiesto porovnavania.
V produkcii som sa zatial stretol s generovanim SQL skriptov s EF, pretoze administratori chcu mat uplnu konktrolu nad tym, co sa nad databazou spusta.
Visual Studio Database Project, ak ide o zlozitejsie operacie ako len zmena struktury, tak by to slo heknut cez tabulku migracii a pre-skriptom (trie sa myslim vykonavaju vzdy). No suhlasim, ze to nie je nativne riesnie.
RedGate mal VS projekt velmi podobny ako staremu dobremu Database Projectu, ale namiesto schema compare sa tam pisali migracie: Redgate SQL Change Automation. Ale nikdy som to nepouzil, navyse je to teraz to stoji 3000 eur
Ad EF migrations: neviem, nemam skusenosti s EF, ako pisem bolo to uz davno, nam ale update schema v NHibernate fungoval, ono to malo dva mody, jeden, ze si isiel oproti live databaze a druhy, ze ti predgeneroval sql prikazy na update, a ty si ich mohol vytunovat a aplikovat manualne.
ad RedGate: mam licenciu v ramci starych MVP benefitov, takze pre mna to az tak drahe nebolo, ale fungovalo to celkom pekne dal si prod db a devel db a vygenerovalo potrebne scripty, ty si ich uz len zaintegroval do aplikacie.
Vratme sa ale k teme migracii db. Co som mal zatial skusenosti, tak sa najlepsie osvedcil sposob zapisovat verziu db do db a robit update podla verzie db, to znamena, ze sa program/service nespustil ak verzia databazy nezodpovedala verzii, pre ktoru bola aplikacia vyvinuta. To samozrejme predpoklada osobitny DB updater, ktory ak je win aplikacia mohol byt sucastou aplikacie, v pripade service/web aplikacii bol osobitnym projektom.
A najlepsie sa osvedcilo upgrade cez predgenerovane sql scripty, nejaky magic zavanal casom problemami.
Prednaska je velmi relevantna k teme, diky. Prislo ako na zavolanie.
V skratke: SSDT (Database Project)
super pre vyvojarov
odhalenie chyb, kedze pri builde sa validuje cely projekt. Napriklad pri premenovani stlpca sa zvaliduju vsety views
lahsi code review
lahko moze z produkcie zmiznut napr nejaky index, ak ho tam admin manualne pridal
tazsie sa do pipelineny intergruje review change scriptov
DpUp, FlyWay:
automatizuju deployovanie migracii
uplna kontrola nad skriptami, ktore sa spustaju
jednoduche a rychle
nachylnejsie na chyby: po spusteni migracie sa databaza lahko dostane nevalidneho stavu. Napr po premenovani stlpca zabudneme updatnut views
ak migracie pise viacero ludi naraz, jedna migracia moze prepisat zmeny v druhej a velmi tazko sa to odhaluje v code review, kedze nevznikde ziadny conflikt v source controle
Redgate Sql Change Automation:
Kombinuje state a migration based pristupy - to najlepsie z oboch pristupov
Podobne ako SSDT validuje vysledny stav, zaroven umoznuje pisat alebo customizovat migracie.
super pre vyvojarov
lahko moze z produkcie zmiznut napr nejaky index, ak ho tam admin manualne pridal