Dizajn baze

Jednostavno u dvije tablice.Tako bi bar ja napravio.Jer skladište koristi više poslovnica pretpostavljam.Čak je tako po meni i sigurnije knjiženje.
Najmanje dvije tablice.

pa u biti baza je od pocetka zamisljena kao 'master-detail' i da bude normalizirana do razine 2.

sto se tice odnosa poslovnica-skladište logično je da su odvojeni, u biti tako san ih i napravia, al ne be tija da kasnije u razvoju naletin na neki problem koji će dovest do toga da je bilo bolje da san strpa sve u jednu tablicu.

Data warehouse :-D?

Jedini primjer u cijeloj mojoj 'karijeri' gdje sam vidio da netko denormalizira schemu.

u firmi u kojoj radim, dizajn baze za financijski sustav na kojem radimo je blago rećeno očajan. od početka nije napravljen kako triba, ljudi koji su to započeli su otišli, a ovo koji su ostali samo krpaju sta mogu. svaka promjena u programu zahtjeva poprilično posla. UŽAS!

sad kad god poćinjen novi program prvo se uvatin dizajna baze. normalizacija obavezna!

90% DB aplikacija koje sam napravio (a ima ih nekoliko stotina) su klijentski orjentirane, i to sasvim dobro funkcionira čak i u višeklijentskom okruženju. Međutim, ono "idealno" po meni bi bio serverski orjentirani pristup gdje baza osim storage funkcije ima i funkcionalnost same obrade podataka. Znači, klijent bi trebao biti tek školjka koja poziva stored procedure. One će se na serveru izvršiti puno brže, te su mnogo prikladnije u slučaju izmjene funkcionalnosti. Tada se ne mijenja klijent već samo procedura na serveru jer je lakše izmjeniti nju nego npr. 20ak klijenata, a kamoli stotine ili tisuće.

Također, rekao bih da je model (dizajn) baze zapravo najvažnija stvar jer to predstavlja nekih barem 70% posla. Kada se ispravno definira tok podataka (u čemu je najveći broj grešaka) onda se radi model baze. Znači, imaš nekakvu priču pred sobom: "Štef iz skladišta S1 nosi materijal poslovnici P1, dok poslovnica P1 taj materijal prosljeđuje skladištu S2 i S3 itd itd..". I tu je već jasno kakva je veza među podacima, kakav treba biti referencijalni integritet itd.. A kako ćeš ti to rješiti na klijentskoj strani (ako uopće takav pristup želiš) je sasvim druga stvar. Možeš radi testiranja to raditi i lokalno (npr. xml) pa kasnije replikacijom prebaciti na server. Tu je već tehnika na milijune, no niti jedna neće dati zadovoljavajuće rezultate ako baza nije dobro postavljena od samog početka jer u krajnjoj liniji i GUI tek radi s podacima.

Slazem se da je dobra stvar u bazu postaviti stored procedure za komplicirani visestruki insert, ali dodavati logiku u bazu je cisto overloadanje odgovornosti. To je posao za application server.

Ne zagovaram izradu rich-klijenata, vec pokusavam objasniti da poslovni model podataka != baza. Baza samo sluzi da se ti podaci spreme, odnosno, idealno bi samo tome trebala sluziti. Brzo spremanje, brzi update, i jos brza pretraga. Modificiranje podataka, kalkulacije, etc - aplikacijski server. Kako vidim jednako razmisljamo, samo sto ja ne zovem te relacije 'baza' nego 'poslovni model' - baza je za mene iskljucivo samo software koji podatke sprema i brzo pretrazuje.

Tracer, tvoja poanta sa bazom stoji ako negiras vrlo bitan argument koji sam ja dao, a to je cinjenica da u vecini slucajeva ne mozes ocekivati definirani model podataka i relacije unaprijed, a kamoli ocekivati da se to nece mijenjati. Odrzavati jedan kompleksan sistem kakav je baza je puno teze dok je aplikacija u razvoju, i taj dio se jednostavno treba ostaviti na kraj, ako zelis najbolje rezultate. U zadnjem dvogodisnjem projektu sam od pocetka do kraja primjenio tu filozofiju i baza se dodala u finalni produkt tek u zadnja 4 tjedna. U medjuvremenu smo koristili filesystem storage uz 'inteligentnu' refleksiju koja je automatski prepoznavala kako spremiti i updateriati objekte. Definitivno nije optimizirano, ali je za development dusu dalo, jer se ne trazi odrzavanje.

Zbog istog tog razloga 'planiranje planiranje planiranje' pada u vodu jer klijenta ne interesira planiranje, klijent hoce aplikaciju i moze se predomisliti svake sekunde.

Ostavit cu par linkova za kraj, pretpostavljam da su prva dva po redu obojici poznati:

http://en.wikipedia.org/wiki/Three-tier

http://en.wikipedia.org/wiki/Extreme_programming

Ostatak se vise odnosi na paradigme i moderne ideje, i ja stojim iza njih ko kamen jer su se za timove koje sam ja vodio pokazale kao pun pogodak.

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://en.wikipedia.org/wiki/Business_model

http://en.wikipedia.org/wiki/Domain_specific_language

@Deus ex machina

Ljudi koji niti sami ne znaju što žele uvijek će predstavljati veći trošak nego zaradu. Čak niti ja kao freelancer nikada ne radim za onoga koji mi ne dade točnu specifikaciju zahtjeva, a kamoli da bi to trebala neka ozbiljna firma. Bez specifikacije zahtjeva ti prije svega nemaš dokaza da si napravio ono što se od tebe tražilo, i on te može vući za nos godinama sa svojim premišljanjima, i na kraju ti opet može jednostavno reći "nisam tako to (za)mislio". Stoga, ono što se navede u specifikaciji je sveta riječ i bez toga posao se niti ne počinje. A ako on hoće s vremena na vrijeme mijenjati specifikacije onda mu se prvo naplati dosadašnje odrađen posao, pa onda neka on mijenja što hoće i koliko god puta hoće, jer ja tada znam da ništa ne radim badava. A ako firma na osnovu specifikacije zahtjeva nije u stanju napraviti fiksni model onda takva firma je neozbiljna i sama sebi stvara viška posla. Model mora biti strogo i unaprijed definiran. Validiran pravilima i provjeren nekim testnim podacima tj. da li na osnovu raspoloživih ulaza se u RAZUMNOM VREMENU dobije TOČAN i VALIDIRAN izlaz u ŽELJENOM OBLIKU. I to je cijela filozofija.

No opet, današnje vrijeme za neke firme je dosta teško pa prihvaćaju bilo kakve poslove. Ali zato imaju ljude koji su specijalizirani samo za ovakve stvari: Da unaprijed definiraju i provjere tok podataka i da za programere prirede model baze.

Kao sto sam vec napomenuo, ne koristim izraz 'baza' za relacijski podatkovni model. Jer 'baza' je obicno sinonim za software koji omogucava relativno jednostavnu izradu relacijskog podatkovnog modela. S obzirom da sam proveo odredjeno razdoblje zivota radeci u PL/SQL-u, definitivno se zalazem da se poslovna logika izradjuje u 1. Jeziku koji nije PL/SQL i 2. Van baze. To je argument na 'poslovna logika u bazi', koji je barem po mojem iskustvu pregazen sa jednim dobrim aplikacijskim serverom, thin klijentom i dobrom brzom bazom koja excelira na jednostavnom DML-u. Razvijati poslovni model u nekom modernijem razvijenijem jeziku, sa dobrim compilerom i odlicnim IDE-om je po meni mandatory, i poslove koji to ne dopustaju vise niti ne prihvacam, iz jednostavno razloga sto 'nizi' jezici koce produkciju i vise vremena se trosi na debugiranje i boilerplate, nego na proizvodnju onoga sto je bitno. Podcrtano, vise kosta. Hocu jezik koji omogucava dobru refleksiju i hocu IDE gdje mogu stisnuti Shift-F6 i napraviti rename refactoring po cijelom codebaseu, bez da se pitam da li je nesto ostalo nepromijenjeno.

Ljudi koji inace rade enterprise aplikacije u Javi su ove cinjenice malo 'svijesniji' od programera C# i drugih, nazalost. Nije stvar u Javi kao jeziku, nego u Javi kao platformi - za niti jedan drugi jezik ja nisam vidio toliko siroku paletu mocnih frameworka i librarya, za apsolutno sve domene razvoja. Od igara do ERP platformi. Sa C#om eksperimentiram zadnjih mjeseci, i otkrio sam da VisualStudio sa Resharperom tvori jedan solidan IDE u kojem se moze lijepo raditi - ali me Microsoftova filozofija pisanja librarya, koja veze nema sa OOP standardnima i patternima jednostavno ubija. A tu je i problem nedostatka velikog broja istestiranih, zrelih opensource librarya koji tvore jednu solidnu platformu na kojoj covjek moze mirno raditi i dostaviti software.

Sto se tice GUI-first filozofije, nikad mi se u zivotu nije dogodilo da klijent unaprijed zna sto zeli, ako nema izvrsno definiran poslovni proces ili ideju kako ga poboljsati. Klijenti se obicno pojavljuju s objasnjenjem toga sto zele, a ne objasnjenjem svojeg poslovnog procesa i idejom kako ga poboljsati. Krenuvsi putem da napravim tocno ono sto klijent zeli dovest ce do toga da sam mu dostavio aplikaciju koja mu je beskorisna, i to je vrlo popularna stvar na nasim prostorima - izmedju ostalog, jedan od razloga zbog cega dosta firmi vrti stari software pisan u Cobolu. Novi je deset puta gori.

Barem u mojim poslovnim vodama, od klijenta se zatrazi da posalje eksperta na teren (tj. u nasu firmu) ili da makar dostavi opis svojeg poslovnog procesa. Onda to prodje kroz ruke nasih eksperta koji traze repeticije i grind, koji se mogu softwareom automatizirati. Cak i kad je ovaj proces prosao savrseno (a jos nikad nije), nikad se nije dogodilo da je jedna strana iskomunicirala drugoj savrseno u detalje ono sto je potrebno. Uvijek su tu miskomunikacije, nerazumijevanje prioriteta, etc.

I apsolutno nam je sve to "DZABE" ako ne pokazemo klijentu kako to izgleda, iz jednostavnog razloga jer klijenta ne interesira relacijski podatkovni model. Njega interesira GUI, interesira ga da se aplikacija ne krsi, interesira ga da ne mora investirati u novi hardware i interesira ga da mu grafovi pokazu poboljsanja u produktivnosti.

Da bi se ti njegovi zahtjevi ispunili, aplikaciju je potrebno shiftati lijevo-desno nebrojeno puta, izmedju nas i njegovih poslovnih experata, i potrebno je obavezno imati ispoliran GUI. Jer ako mi imamo neki sasvim dobar feature koji od krajnjeg korisnika trazi da na ruke uredjuje XML - onda ne treba cekati dugo da klijent kaze "To nije ono sto smo trazili, hvala i dovidjenja".

Po mojem iskustvu, ako vasi klijenti unaprijed imaju dobro definiran poslovni proces i model, i od vas uopce ne traze poboljsanje vec samo novu aplikaciju koja je u principu novi skin koji radi na windowsima, ja vas smatram sretnicima. Nasi klijenti definitivno nemaju pojma sto zele, osim cinjenice da imaju novac koji zele spiskati na nas proizvod. Komunikacija je kljucna, kao i sto brze promjene.

Sto se tice osobnog rada, dakle na nivou jedne osobe, kad dobijes za task implementirati neki feature - recimo, klijent mora biti sposoban preko jedne forme isprintati svoje reporte ili ih prikazati na ekranu - najbolje sto mozes je krenuti od GUI-a. Svaka cast ako ti je reporting engine super-mocan, ali to nikoga ne briga ako ti je gui katastrofa. Zato lijepo krenes i kalkuliras da ti gui bude sto jednostavniji, sto manje klikova, sto manje kontrola, sto vise pameti. Klijent uz sto manje citanja i sto manje klikova mora dobiti tocno ono sto zeli.

Tek kad si to napravio, ONDA mozes znati kakav tocno linking-layer izmedju modela u guiu (mislim na MVC design pattern) i poslovne logike moras sastaviti. Gdje ces ubaciti auto-completition. Gdje ces popraviti datum automatski. Gdje ces biti pametan za korisnika tako da on ne mora biti. I tek kad si to ispolirao kako treba, onda mozes razmisljati o slanju HTTP requesta na application server da bi dobio kalkulacije reporta natrag.

Sve novotarije u poslovnom programiranju postoje iskljucivo zato da bi se cim brze inkorporirale promjene u aplikaciju, a bez da se codebase zasmrdi toliko da ga se vise ne moze odrzavati. Dovoljno je pogledati Domain Model Architecturing, Service Oriented Programming, Code generation i ostalu gomilu trendi-rijeci i trendi-siteova da bi se vidjelo da vode nisu uzburkane oko toga jer manageri vole nove rijeci, nego zato jer programeri i arhitekti trebaju nove i snaznije alate i paradigme da bi u istim rokovima izgurali sve kompleksniji software

Cisto na kraju, jos jedan mali bottoms-ground argument - Hibernate i NetHibernate ORM framework, najpopularniji ORM library trenutno na trzistu.

Da se aplikacije razvijaju iskljucivo od baze pa nagore, taj vrlo popularni framework ne bi razvio svoj DML jezik nazvan HQL, i ne bi dopustao jednostavan retargeting persistence layera (trenutno je izbor Oracle, MySQL, Postgres i HypersonicSQL) uz jedan parametar.

Nikoga ne bi bilo briga za tu opciju.

Cheers!

To se zove premature optimization in my language :-)

Nitko, ni bog ne zna sto je sporo ili sto nije modularno dok se aplikacija izradjuje. Ja konstruiram po prirodi vrlo modularne komponente, ali definitivno svako toliko uleti neka izmjena na koju nisam mislio. Zato svakodnevno zahvaljujem bogu na tome sto je izmislio OOP i interface.

A kasnije profiler odlicno posluzi da vidim sto trebam popraviti da bude brze.

To nisam vidio za 9 godina svojeg radnog iskustva, od toga zadnje dvije godine u produkciji video igara.

Mislio sam da taj odnos arhitekt/programer postoji jos samo u povijesnim knjigama, Hrvatskom Vodovodu, vojsci ili nekoj slicnoj monolitnoj organizaciji koja se nije maknula iz prapovijesti pisanja softwarea.

Onako zaozbiljno, programera koji zna samo 'nakucati' kod ni ne zaposljavam - za to mi sasvim dobro sluzi code generator koji taj posao obavlja puno bolje.

Povlacim se iz teme, cheers!

Edit:

zaboravio sam se zahvaliti za PDF o GUI-u, cini se dosta korisno stivo! Hvala :-)

Onda moram priznati da prema svemu ovome što si napisao radiš u jako čudnoj firmi koja se prihvaća posla za kojeg niti ne zna što na kraju treba napraviti i koji rezultat treba ispasti jer u svakom trenutku dopušta klijentu da se samo tako premišlja, koja niti sebe ne osigura da može na kraju reći da je obavila posao i koja GUI stavlja ispred baze, jer baza predstavlja podatke a GUI je tek školjka koja radi s bazom. A što se tiče "arhitekta", sa mnom rade trenutno trojica kojima je isključivo to posao - a programeri su im do neba zahvalni jer bar znaju da njihov posao se temelji na dobro provjerenim informacijama o razmjeni podataka i potrebama pojedinih sektora poslovanja, a ne da još programeri moraju glumiti i marketinške stručnjake, ekonomiste i računovođe pa se misliti s kakvim oni podacima rade i što će im sve trebati ili ne.

A što se tiče "nakucati", tu mislim na onaj dio posla kada treba fizički napisati program, a to i nije neki problem kada jednom pred sobom imaš sve pripremljeno i poznato.

I isto tako, produkcija video igara se ne može uspoređivati s analizom nekom poslovanja, sastavljanjem i modeliranjem baze. Koliko god bio dobar u programiranju nikada ne možeš toliko kvalitetno unaprijed sastaviti bazu ukoliko nisi analizirao IO procese, a to nije posao programera.