Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku

[es] :: MySQL :: Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku

[ Pregleda: 1559 | Odgovora: 3 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427



+19 Profil

icon Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku25.04.2011. u 18:25 - pre 157 meseci
Dva su pitanja:

1.- Kako odabrati ispravan tip podataka uzimajući u obzir sve aspekte baze i aplikacija koje se izvršavaju nad tom bazom.

U jednoj od tema vezanih za JMBG povela se diskusija o tipu podatka za njegov smeštaj. Neki su zagovarali dva ineger-a, negi biginteger a neki char(13).
Obrazložeje je bilo da je ušteda u prostoru veoma bitna i ako iznosi sitnih 5 Mb po milionu slogova( duša sa JMB) i da je rad sa intege-ima mnogo brži. Da li je to suštinski tačno?
Ili je možda ipak bolje upotrebiti char(13) i povećati brzinu izbegavanjem nepotrebnih obrada i gimnastike prilikom unosa i prikaza unesenih podataka? Voditi računa da se aplikacija može izvravati na raznim tipovima uređaja i na raznim operativnim sistemima

2.- Gde smestiti poslovnu logiku? Da li u bazu ili u klijentske programe. Šta je kvalitetnije rešenje po pitanju zaštite podataka, jednostavnosti održavanja i brzini izvršavanja željenih operacija?

Kažem klijentske jer postoji mogućnost da bude više različitih klijenata sa različitim potrebama, pravima pristupa pa i sa različitim operativnim sistemima na kojima se izvršavaju.
Da li je korisnije da baza sama obavi validaciju svojih podataka i da klijenti samo obezbede način za unos i prikaz podataka ili im treba prepustiti i upravljanje podacima?
Obratiti pažnju na to da postoji mogućnost pristupi bazi i sa udaljenih lokacija putem nekada ne tako brzih veza i uz pomoć ne tako brzih i pametnih uređaja.

Znači, vrlo je bitno obuhvatiti sve aspekte veze baze i aplikacija koje se obraćaju toj bazi sve vezano za izbor najadekvatnijeg tipa podatka da bi se na kraju sobio kvalitetan proizvod.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku25.04.2011. u 20:05 - pre 157 meseci

onda je mrmot zamotao cokoladu ..


ne postoji silver bullet


Prikačeni fajlovi
 
Odgovor na temu

rambo
Dejan Petković
Beograd

Član broj: 6095
Poruke: 190
*.dynamic.sbb.rs.



+6 Profil

icon Re: Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku25.04.2011. u 23:48 - pre 157 meseci
Najjednostavniji odgovor za pod 2. je Application Server. Višeslojna (u ovom slučaju troslojna) arhitektura je generalno rešenje za većinu problema većih i velikih poslovnih sistema. Kompletna "poslovna logika" se smešta na application server a klijenti su tzv. tanki (thin) klijenti. U takvom okruženju, baza podataka je samo baza podataka i na tom sloju se obično ne implementira nikakva poslovna logika, osim operacija niskog nivoa koje su zajedničke za čitav sistem. App server preuzima sve funkcije validacije podataka i svakog drugog vida interakcije sa klijentom. Klijent se svodi na UI i najneophodnije validacione mehanizme, koji su univerzalnog karaktera ili specifični za implementaciju klijenta. Eventualno, moguće je napraviti više app servera koji će opsluživati različite klijente. Sa više instanci app servera vrlo efikasno se postiže "load ballancing" i obezbeđuje se maksimalna dostupnost (availability) sistema.

Što se tiče tipova podataka, postoje generalno dve mogućnosti. Prvo, u toku projektovanja sistema treba detaljno i pravilno predvideti sve zahteve sistema, čime bi tipovi podataka mogli jasno da se definišu. Drugo, obzirom da nije moguće uvek predvideti sve potrebe sistema, onda se tipovi podataka za neke atribute generalizuju. Najbolji primer za ovo je da se u bazu smešta XML koji sadrži proizvoljne informacije. Kod jasno definisanog sistema se retko javlja ovakva potreba, ali je uvek moguće takav sistem proširiti dodavanjem novih atributa kojima će prethodni biti zamenjeni. Inače, u slučaju korišćenja XML-a, App server je taj koji vrši translaciju između onoga što se nalazi u bazi i klijenta, tako da bi i za prvo pitanje Application server bio pravo rešenje.

Inače, Treba biti oprezan sa generalizovanjem funkcionalnosti sistema. Prvo, bar jedan sloj (najčešće app server) će zbog generalizacije morati da bude vrlo glomazan, a drugo, generalizacijom se obično gubi na performansama.
"There is a theory which states that if ever anybody discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be replaced by
something even more bizarre and inexplicable. There is another theory which states
that this has already happened."
-- Douglas Adams
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku26.04.2011. u 03:32 - pre 157 meseci
dejane, ovo sto si napisao je samo jedan od mogucih nacina dobar za jedan broj aplikacija a opet je vrlo opst i generalizujuci ... kao sto si i sam napisao, generalizacijom samog sistema oduzimas mu agilnost ... da ne spominjemo sta se desava kada generalizujes ceo sistem ...

svaki problem ima svojih n resenja, i svako to resenje zavisi od velikog broja promenjljivih ... ono sto ja radim za leba je bas to, uzimam u obzir veci broj promenjljivih nego sto neko ko radi arhitekturu obicno uzima u obzir i u osnovu na to dajem preporuku koji put je najbolji za taj set varijabli ... nekada je dovoljna mala promena u setu zhatevnih varijabli koja kompletno menja "najbolje resenje", zato, po nti put kazem, nema srebrnog metka, ne postoji resenje koje je univerzalno dobro ...

ja sam se u zivotu nagledao situacija gde inzenjer 3 dana crta uml, 2 dana pise dokumentaciju i 2 dana pise kod za obican glupi parser za neki log fajl koji se koristi "samo jednom interno", dakle umesto da je napakovao za 5 minuta awk skriptu i odradio posao on je izgubio 56 radnih sati da bi odradio taj posao i onda ga "bacio" ... mozda deluje kao glup primer, ali tako bacenih sati u jednoj prosecnoj firmi srednje velicine ima zastrasujuce mnogo...

drugi primer je recimo ORM, vrlo popularan tip frameworka zadnjih desetak godina ... jako popularan zadnjih 5-6 .. to je, recimo, najskuplja greska koju firma moze da napravi .. da me ne shvati neko pogresno, ORM nije uvek greska, ali kada se ORM koristi gde ne treba to moze taaaaaaaaako mnogo da kosta ... ako je neko citao moje primere "debilnih pitanja", vrlo cesto se provlaci "na test serveru je radilo super a sada na produkciji ne radi" (zato sto su na test serveru radili sa datasetom od 100M a na produkciji imaju dataset od 2G) ... u 99% slucajeva kriv je ORM... ako pogledate upite koje prosecan ORM izvrsava - to je da sednes i places.. a ne mozes im nista, ne mozes da ih optimizijujes (iako je vidljivo sa kilometar kako bi mogli da se optimizuju) posto ne mozes da utices na to kako ih orm generise ... onda takva firma kaze "sql je sr4nje, aj sad da koristimo no-sql" i onda pisu prilagodjenje upite za no-sql .... naravno 10000x jeftinije im je bilo da su sada te upite pisali optimizovano u sql-u dobili bi resnje odma koje provereno radi ... (imamo nekoliko primera velikih na netu koji su napravili ceo krug sa ORM->noSQL->SQL kao na primer digg)... opet u mnogo slucajeva, orm resava mnogo vise problema nego sto ih pravi (ERP na primer) pa ma koliko je prica sa bazom iz razloga ORM-a spora, toliko se to isplati sa druge strane....

izbor data storage-a je takodje ogroman faktor ... jeste "sql" univerzalan, ali nacin na koji neke stvari rade ovde i onde nije ... glupo poredjenje mysql i pgsql-a .. 2 najjaca open source rdbms-a na svetu ... ako imamo hiljade jednostavnih upita mysql je neuporedivo brzi dok ako imamo stotine kompleksnih upita (koji odradjuju isti posao u manje upita nego oni jednostavni) pgsql ce odrati mysql... ja rdbms necu odabrati po tom kriterijumu vec po drugim kriterijumima (npr ako mi treba testirano dobra replikacija uzecu mysql, ako mi sa druge strane treba potpuno otvorena licenca i necu da se smaram sa advokatima uzecu pgsql) pa cu onda u odnosu na to koju sam bazu odabrao da resim jedan problem u 3 jednostavna upita ili u jednom kompleksnom .. da ne spominjemo oracle, db2, teradata i ostale "velike" baze podataka ...

dakle svaki odgovor na originalni post koji preferira bilo koje resnje spada u domen mrmota i cokolade.... CPU jeste dzaba i tacno je da se mnogo povecao, HDD space jeste dzaba i mnogo se povecao, RAM jeste relativno jeftin a nije bas nesto mnogo poskocio (ja trosio 64-128G masine pre 10 godina, sad trosim 128-256G masine ... i nije neki drastican pomak, samo duplo) ali ako uporedimo koliko je data danas veca, data se povecala mnoooooooooooogo vise nego sto se povecao i cpu i hdd i ram ... sredne preduzece sada operise sa mnogo vise date nego sto je operisalo pre 10 godina, da ne spominjemo pre 20 godina ... da ne spominjemo "velika" preduzeca i velike sisteme ili nedaj boze socijalne mreze i online aplikacije koje su odavno prevazisle komparaciju sa enterprise aplikacijama posto jedna velika socijalna online aplikacija barata sa vise podataka nego ogromna spediterska kuca...
 
Odgovor na temu

[es] :: MySQL :: Kako odabrati ispravan tip podataka i gde smestiti poslovnu logiku

[ Pregleda: 1559 | Odgovora: 3 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.