Zaujimalo by ma, aky pristup ste zvolili pri verzionovani a deployovani SQL.
V principe vidim tri moznosti:
State Based (datazovy projekt) - super nielen kvoli refaktoringu SQL schemy, ale aj verzionovaniu a code review
Migracie - super na automatizaciu CD, ale napr refaktoring a historia.
Nejaka kombinacia. Ak nenajdem dobry free tool, tak rozmyslam aj nad databazovym projektom a rucne pisanymi migraciami. Schema Compare by som pouzival iba na validovanie migracie
Nenapisal si, ci pouziva EF, dapper, alebo ci si pises SQL-ko sam.
Kedysi som pouzival datazovy projekt, lebo to bola firemna kultura, plus na vlastnom projekte som pouzival CRL funkcie a tie sa lahsie pouzivali a nastavovali v databazovom projekte (v dnesnom stave si na tento jeden projekt pisem migracie rucne)
Dnes kde sa pouziva EF, tak to riesim migraciami, tak, ze CI vypluje indepotentne migracne skripty. Takze tie sa nasledne zoberu a aplikuju na server.
Inac, je vbec mozne pouzit moderny .Net pre CRL funkcie? Alebo nejaka moznost ako dostat funkcionalitu blizko ku datam v SQL serveru.
EF Code first a s EF migraciami sa mi zdali prilis obmedzujuce. Navyse, stale to akosi neriesi problem s verzionovanim viewov, funkcii a podobne.
Stale si vies vytvorit prazdne migracie a do nich dopisat SQL-ko, ktore potrebujes, povazuje sa to za odporucany postup.
Ja som tak riesil fulltext a nejake stored procedury.
CRL funkcie ani neviem co su. Myslel si CLR?
Hej myslel som CLR. typicky priklad je hladanie pomocou regexu v MS SQL, alebo nejaka praca z grafom, kde potrebujes spracovat vela dat, ale vysledok je maly, tak je lepsie mat tu funkcionalitu blizko pri datach (samozrejme nechcem to zneuzivat na aplikacnu logiku).