V reakcích na můj předchozí příspěvek se objevily názory (za které tímto děkuji), že bych měl spíš všude v kódu promítnout tu změnu, která se stala na úrovni databáze, čili přejmenovat si sloupce i ve své aplikaci. Já jsem se původně vůbec nechtěl pouštět do jakéhokoliv popisu situace, ani toho, co mě vedlo k tomu, dělat to tak, jak to dělám. Mě ta reakce vlastně překvapila natolik, že jsem ani hned nedokázal patřičně reagovat, a vysvětlit proč to tak dělám. No, aspoň jsem si to v hlavě utřídil.
Databáze je nějaký koncový bod. Když se změní databáze, tak jediné, co chci říct aplikaci je: Data bereš odtud. Případně, tady k tomu ještě máš pár parametrů. Pokud musím něco měnit v té vlastní aplikaci, tak je to (podle mého názoru) blbě. Neboli, mám vrstvu (řekněme driver), která se stará o to, abych od databáze dostal data. Různé drivery pro různé databáze. Když si představím, že ta aplikace není nějaká vnitropodniková záležitost, ale něco co prodáváme, a něco co podporuje různé konfigurace jistého ERP, tak nebudu mít několik verzí kódu pro různé konfigurace toho ERP a různé databáze. Jediné co budu měnit, bude connection string, a možná pár parametrů. To vidím jako jedinou správnou cestu, a nevidím důvod, proč by to mělo být jinak jenom proto, že nikdy žádná druhá instalace toho software nevznikne.
Přece dám jednomu komentujícímu za pravdu v tom, že když už jsem empiricky o té databázi, nebo spíš o tom ERP zjistil, že používá ten prefix t$ nebo t_, tak bych měl správně ze všech míst ze svého kódu tyto prefixy vyhodit. Protože prefix je dost pravděpodobně konfigurační parametr toho ERP. O překlad jména sloupce mezi aplikací (bez prefixu) a databází (s prefixem) by se měl postarat driver.
Nerek bych ze je to ujasneno ... ;D
Pokud mam nejakou aplikaci, tak ji muzu provozovat nad nejakou databazi ktera ji patri = app + db je "jedna" vec. Potom je logicke, ze nazvy tabulek si urcuju ja (nebo nekdo semnou, to je fuk) a je nelogicke resit jakekoli prevody nazvu.
Variantne muzu mit app, ktera bezi nad nejakou DB treti strany. Pokud takova DB umoznuje kreativitu v nazvech tabulek (moc takovych teda neznam), tak mi nejaky parametry jsou naprosto na kulovy, protoze technicky se tabuka rekneme s uzivatelema muze jmenovat "uzivatele", "users", ...
Tahle varianta se nejrozumenjs resi tak, ze si udelam vlastni DB, do ktery si dle potreby naladuju views, ... s nazvy, jaky se libej me (jaky pouziva moje app). => co budu muset vzdycky prepisovat je samo nejaky ten create script.
Technicky se mi totiz muze stat (a stava se) ze dodavatel one DB(SW) se rozhodne, ze si pejmenuje nejaky ten sloupecek v databazi (zazil sem osobne nekolikrat), a pak je mnohem snazsi a efektivnejsi upravit ty pohledy nez prekopavat aplikaci (kde se ten sloupecek muze pouzivat na hromade ruznych mist).
1: udelam vlastni databazi: a jak, ty chytraku ? to je hodlas donutit aby ti zmeny replikovali ? nebo chces nejakou prasarnu stylu "linked table" a kvuli tomu udrzovat dalsi databazovy server / engine (ktery to bude zpomalovat, musis ho zaplatit a to vcetne cloveka co ho bude udrzovat ?)
neni nahodou lepsi mit primo v aplikaci (= zadarmo co se naroku na vykon i udrzbu tyka) mapovaci vrstvu, inicializovanou treba (zadny recompile nebo drop+create/alter view) z nejakyho konfigurcniho souboru (pro prasata tvyho "systemovy reseni" kalibru klidne XML) a pohoda veget ?
NEEEE, zapojime SAP, Oracle, MSSQL a pokud to nebude jeste dost zkurveny, pridame mezi to jeste MS ACCESS a DBASE ...
Tvoja predstava je naivna. Teraz sa ti zmenil nazov stlpca, co budes robit, ked sa zmeni napr. domena? Uz to nebude byte, ale integer. Tvoja aplikacia s tym nebude pocitat a vies, co sa stane potom. A co ked z/denormalizuju nejake tabulky? Alebo stlpec A premenuju na B a B na A?
Vo vseobecnosti pokial chces pristupovat k roznym verziam databazy, je dobre mat medzi databazou a business kodom vrstvu, ktora to prekryje (persistence layer). Potom len vymenis vrstvu podla toho, k akej databaze pristupujes.
Ziadne "data beries odtud" neplati. Vzdy musis poznat schemu databazy a podla toho tahat data.
4: Já jsem se do této debaty vůbec neměl pouštět, protože o tom vpodstatě nic víc říct nechci, ale: Mě se nezměnil název sloupce, ale názevy všech sloupců tak, že už nemají prefix t$, ale t_. To není změna, to je tak nanejvýš dekorace. Schéma se nezměnilo ani nezmění.
Řeknu: data bereš odtud, a podle toho se přizpůsobí/vymění driver neboli persistence layer. Nemluvíme náhodou oba o tom stejným? Mluvíme. Ale rozumíme si? Já jsem se to této debaty vůbec neměl pouštět, protože prostě neřeknu další detaily.
4: Kdyz se zmeni domena, pravdepodobne se zmena promitne do dalsich casti programu. Pak budou rozsahlejsi zmeny nutny.
Ale to nic nemeni na validite autorem zvoleneho pristupu. Dodrzuje "dohodnute" rozhrani (ok, DB je spatny integracni bod, ale cert to vem, API "nedali" ...), a dokud se ho pridrzi, kazdymu muze byt (a bude, nikdo si toho nevsimne) jedno, jestli sloupec interne nazyva t$nazev_polozky, t_nazev_polozky nebo brambora.
Vyresil svuj konkretni problem, to ze neresi tvuj teoreticky pseudoproblem *1 mu nezazlivej a nepredhazuj ;-)
*1) neco co resit nezamyslel a co se predem resit neda - co kdyz udelaji z bajtu datum, nebo ze stringu obrazek ... Vyctes mu taky ze mu to nepomuze v pripade ze sloupec pribude ?
Jmenuju se Petr Blahoš. Programuju něco přes 20 let. Tady se snažím psát hlavně o Pythonu, webovém frameworku Pyramid, a občas i o něčem úplně jiném.
Přečteno 19 309×
Přečteno 11 880×
Přečteno 9 408×
Přečteno 8 866×
Přečteno 8 651×