K tomu psani kodu v PgAdminu a podobnych nastrojech.. (ted trochu ze strany vyvoje oracle a PL/SQL a nastoje k tomu).
Kod se ma psat v IDE ktery je na to urcene, psat to v editoru x je sice mozne, ale z daleka nie je to tak pohodlne jak k tomu urcene IDE. Naseptavani, hinty, warningy, chyby z kompilace.
Souhlas s dalsima nazorama z te sekce, ale rekl bych ze vyvoj v IDE pro PL/SQL a nad tou databazi (idealne se stejnyma strukturama, i kdyz je to jenom nejaka lokalna kopie), je pohodlnejsi a bezpecnejsi.
Ono je jedno, jestli to píšete v PgAdminu nebo v něčem .. důležité je, kde jsou zdrojáky uložené. Je chybou, když při deploymentu děláte reverze engineering databáze. Navíc přicházíte, jak už bylo zmíněno, o verzování, větvění, v podstatě přicházíte o jakou koliv moderní správu kódu ... K tomu mám zkušenost, že díky tomuto stylu se na produkční databáze zanáší nehotový, mrtvý kód.
Bohužel pro Postgres žádné kvalitní cost free prostředí neexistuje (podle mého gusta). Existují extenze do Emacsu a i Vi, nicméně to asi nebude pro každého.
U compilovanych objektu PL/SQL, ci PL/pgSQL (package, procedury, funkce view, pripadne i objektove typy) reverse engineering potreba nie je. Create a replace to resi. O to horsi jsou tabulky (a typy/objekty s navaznostama na dalsi typy).
A to je ta cast kde prave dane IDE exceluje. Ano kod bude v DB, ale nic mi v tom nebrani abych to ukladal do souboru, verzoval.
Nemit zdrojaky v DB je jednak nemozne, a jinak clovek by prisel i o to ze vlastni praci 'zvaliduje'.
Nemit zdrojaky v mimo DB je taky blbe, clovek prijde o historii vlastni prace (krasna znama situace kdyz to nekdo prepise), nemit je verzovane na dlhodoby projekt docela nemozne.
Verzovani, vetveni potreba, tie argumenty ani nepopiram, ale s IDE/nastojema ktery to primo kompiluju do DB a resi veskere navaznosti na dalsi objekty.
Bohuzel ani pro Oracle zadne free cost reseni na to neexistuje.
K verzovani nasazovani je tam mimojine Liquibase (ne jenom oracle ale kopa dalsich sql databaz), ktery pomaha k verzovani a rollbacku, dobre se integruje do CI, ale trochu i pridava praci.
Možná si představujem trochu něco jiného pod pojmem reverse engineering. Pokud nemáte větvě, tak všichni jedou jakoby v masteru - a jelikož se bojí přepisu, tak pushují i nedodělanou práci. Pokud by dva uživatele upravovali stejnou funkci, tak to dopadne špatně. Tím rychlým pushováním se vám do mástera (nic jiného neexistuje) může dostat nedopečený kód. A jelikož se dělá komplet deployment - tak takový kód se dostane i na produkci.
Když máte kód primárně v souborech a ve verzovacím systému, tak můžete udělat merge, rebase - kolize zjistíte.
Samozřejmě, že pro testování ten kód nahraji do db - a zde je umím i zvalidujovat - to se jinde udělat nedá.
Ještě jedna poznámka - ve své poznámce jsem primárně cílil na Postgres. Práce s db objekty, kompilace, řešení dependencí je v Postgresu hodně jiná než v Oracle. To vyvedení db objektů do souborů se v PG udělá jednodušeji - v některých případech je i nezbytné (např. u pohledů). Navíc Oracle má packages - a kód z packages má hodně podobný formát tomu, co by vzniklo, když uložím pg zdrojáky do souboru.
Určitě se nebráním kvalitnímu IDE - a kdybych nebyl líný, tak bych si napsal makra do Emacsu nebo geditu (zas na druhou stranu nemusím udělat všechno sám :)). V každém případě, to na co jsem hlavně upozorňoval je použití čistě pgAdmina - který sice umí autocomplete, ale neumí verzování, zahazuje vnější komentáře - a nemá nic, co by umožňovalo vytvářet vyšší celky ve smyslu modulů nebo packages.
Jo, slo o nedorozumeni s reverse engineeringem.
K verzovani kodu by to chtelo jeste rozumny build system, a nejaky volne dostupny, jednoducho pouzitelny pro Oracle jsem taky nenarazil.
Vyvedeni kodu z oraclu do souboru problem nie je, u tabulek diff mezi systemama je trochu horsi. Porovnani s PG nemam, skusenosti s PG nejsou moc hluboke.
Kvalitne IDE pro Oracle existuji, ale u kazdeho chyby neco..
Bohuzel vyvoj na databazemi v nekterych kulha nekde po ostatnich systemech, tak s toolingem, best practicema a obecne s ekosystemem. Minimalne ve sveta Oraclu.
Žádné lowcost řešení neexistuje. My máme development, test, smoke - test a production verze db. pravda v MS SQL, ale to na principu nic nemění. Developer v podstatě na základe jira tiketu vykoná praci pomocí create / alter. pak se z db vygeneruje kód a uloží jako Git branch, následuje merge request a jednou týdne release do Test -> Smoke Test -> Production to vše za pomoci Jenkins. ale od CI to má ještě hodně daleko. ze začátku to byl celkem bolestný proces, ale teď už je to v poho. Jako větší problém vidím unit testing t-sql a úplně nejhorší je jakykoliv testing MOLAP kostek, které jsou nad zmíněnými DB.