Projekat modelovanja baze od nule do finalnog resenja

Da li ste zainteresovani da odradimo bazu od nule?

Moja zamisao je da to izgleda kao jedan projekat koji bi ovde bio dostupan svima.
U tom projektu bi se krenulo od ideje sta modelovati, koji su zahtevi i sve sto bi moglo jos da se doda.
Isli bi od pocetka, i tako omogucili svima da se vidi kako se modeluje nesto od ideje do finalne baze sa svim pitanjima/problemima/mogucnostima koje donosi modelovanje MySQL baze.

Nadam se da je ideja dobra i da ce to omoguciti da se mnogo toga nauci kroz jednu temu u kojoj bi bile sve faze modelovanja i pravljenja sql upita/view/...

Ako se slazete, mogli bi da krenemo jer ja imam par ideja pa bi mogli da ih razvijamo i modelujemo...

Pozdrav svima

imas brdo takvih primera na netu, postupno i objasnjeno
- klasicna bibliteka
- klasicno knjigovodstvo

pogledaj: http://www.databaseanswers.org/data_models/

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Zdravo,

Hvala na linku, odlican je.

Da, to je prilicno impresivna stranica sa modelima, ali ovde je cilj da se krene od nule i da se pokaze razvoj od nule a ne da prikaze gotovu bazu.
Verujem da se iz jednog takvog projekta moze dosta nauciti ako se cita razvoj cele price.

ja sigurno necu da guram klipove u tockove ako ima zainteresovanih

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Moze li ovakva tema za razmisljanje?


Ako ste zainteresovani da napravimo model baze srpskih reci.

Zahtevi bi bili:
1) baza treba da sadrzi sve reci, i one osnovne i one koje su dosle promenom osnovih reci (ukoliko su promenjive. i te promene bi bile po rodu, jedini/mnozini/padezima/vremenima)
***) osnovne reci mogu da imaju vise znacenja

2) svaka rec koja je nastala promenom treba da sadrzi tip promene, opis promene, primer/primere

3) pretarazivanje treba da bude :
***) po osnovnim recima
***) promenjenim recima
***) po tipu reci (imenice, zamenice, brojevi, pridevi, glagoli, prilozi, predlozi, veznici, uzivici, rece)
***) po dodatnim atributima koje neke osnovne reci mogu imati (kao sto su turcizam, medicina, botanika....)
***) za zadatu rec, treba naci onu koja se rimuje
***)

4) povezati sve reci koje mogu da nastanu od te reci prostom permutacijom neke zadate reci (mogu se izostaviti slova iz reci) :
---) primer, za rec prestolonaslednik , mogu se dobiti reci : prst, sto, naslednik, presto, slano, slan, so, klen, klin, presno

Verovatno mozemo da smislimo jos neke zahteve...

ko ce da unese podatke?

Potpis

Acta, non verba!

glupa ideja, moze to bolje

Glupa ideja?

Daj argumente zasto je glupa, da bi mogli da je ispravimo.
Ako vec kazes da moze i bolje, daj bolju ideju.

Sto se tice popune baze, to ovde nije pitanje. pitanje je kako je modelovati da sto bolje ispunu zahteve.

Evo od mene prijedlog (pošto sam počeo da radim nekakav manji projekt kroz koji ujedno i učim, i svakako bi tražio pomoć i postavio zasebnu temu)

prisustvo na radu, obračun sati,... i ko zna na kraju sta ispadne još...

EVO SLIKE MODELA

prijedlog, sugestija,... ??

1. uploadujes sliku uz poruku tako sto kad zavrsis poruku ispod nje ti se pojavi "dodaj fajl uz poruku" ili tako nesto, mnooogo bolje nego da dizes slike na razne sajtove pune reklama

2. normalno je da se tabele zovu u jednini. cak i ako iz nekog razloga odlucis da ih zoves u mnozini, onda opet SVE tabele zoves u mnozini, nikako ne zoves neke tabele u mnozini a neke u jednini (sati - mnozina, radnici - mnozina, razlog - jednina .. ) dakle sat, radnik, stamp, razlog (ne znam sta je "sihta" ?)

3. ili ces da pises na srpskom (hrvatskom, bosanskom, crnogorskom...) ili na engleskom, ne moze radnici i stamps ili su radnik i pecat ili worker i stamp ... nemoj da mesas

4. ID - u stamps imas radnici_id a u radinici imas samo id, kada imas veliki upit ne vidi se lepo sta je sta zato se te kolone nazivaju uvek isto te umesto sati.id imas sati.sati_id.. radnici.id treba da bude radnici.radnici_id etc etc .. jer ces onda imati neki upit .. select ... join radnik, stamp using (radnik_id) umest join radnik, stamps on (radnik.id = stamp.radnik_id) .. ono prvo je jasnije, preglednije ...

dalje sto se samog modela tice, iz modela se ne vidi sta ti je zahtev, pa mozda pre nego krenes da crtas model, napises sta ti je zahtev

takodje, deluje da si crtao ovo u mwb-u, posto dosta ljudi koristi mwb (a ko ne koristi trebalo bi) onda je zgodno da uploadujes uz png modela i mwb fajl

(mwb==mysql work bench => i dalje ne dovoljno dobar kvalitet aplikacije ali sto ga vise ljudi koristi brze ce se isterati svi bagovi. za svaki bug koji primetite, molim vas da ga submitujete na bugs.mysql.com)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

1. vjeruj trazio sam dugme, ali tek sada vidim da se pojavi kada postavis odgovor...

2. posto su ovo tabele samo dio veće baze, i nisu vezane za temu nisam ih pokazao, na kraju ce biti poslozeno i vjerovatno sve na engleskom

3. nisam moga da nadem kratku odgovarajucu rijec za stamp :) i jos pokoju riječ

koristim MNOŽINU, samo ID u tabeli kao PK, jer tako zahtijeva datamapper pisan za codeigniter, (moze se zaobići mnozina ali se odstupa od pravila...,ali ID polje mora da ostane)

-- sihta je skraceno od šihterica :)


MWB koristim ali često mu se desi da krahira, ne znam zašto, i svaki put ga pustim da pošalje report,...


Zahtjev bi bio EVIDENCIJA RADNOG VREMENA:

1. radnik dode na posao prijavi se...
2. krene napolje odjavi se...uz nekakav razlog odlaska...teren, isporuka,...
3. vraća se ponovo se prijavljuje...
4. kraj radnog vremena, odjava....

5. program obrađuje podatke i slaze ih u SIHTU (šihterica),...
-------------------------------------------------------------

Zdovoljava li ovaj model te zahtjeve,...npr, da li je potrebna još jedna tabela npr. stamps_archive gdje bi se arhivirali procitani podaci, radi brže obrade a i ne bi morali postavljati dodatnu kolonu za flag,...

posebno pogresno kada je u pitanju engleski jezik



bilo kakvo ucenje i rad nad database modelom je kompletno pogresna stvar ako se isti limitira debilnim ORM zahtevima. Svaki framwework koij te tera da ti menjas zahteve prema njemu je los framework. Svaki ORM i svaka govnarij* koja ce "umesto tebe da pise sql" ce generisati vise problema nego resenje. Danas ne postoji ni jedno orm resenje koje valja, ne postoji cak ni jedno resenje koje je upotrebljivo, posebno ako pricamo o PHP-u koji inicijalno sluzi za web sto znaci da stranica mora da radi brzo i da ce joj pristupiti mnogo ljudi.... Ako ti hoces da se samoprevaris zatvarajuci se u zacarani krug tih pogresnih poluresenja to je tvoja stvar, ali nabacivati takve limite na model za ucenje je vec nedozvoljivo.



morao sam da proguglam da vidim i to sta znaci :D, sva sreca google zna hrvatski :)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Onda prepravljamo da ide po pravilima,...

Datamapper za CodeIgniter je pisan iznad CodeIgniter query builder-a i veoma je fleksibilan, tako da ako ti u nekim slučajevim ne odgovara ORM, ti pređes ba CI query builder... ali to je druga tema...

evo ponovo prilog, sa slikom, sql script-om i MWB model.

mnogo bolje :D

zamerke - sihtarica:
ja razumem ovu sihtaricu kao "punch card", ako sam pogresno skonto taj deo onda ovo sto pisem nema smisla :D

- "pravila" u firmi se menjaju, ali se nikad ne menjaju retroaktivno
- ako sam ja dosao na posao danas u 7 ujutro a otisao sa posla sutra u 1 ujutro ti to ovde ne mozes da obradis kako treba, ja bi izbacio "datum" i prebacio da od i do budu datetime ili timestamp
- napomena je varchar polje koje trosi resurse a bice ovde u promilu slucajeva, bolje ti je da imas externu tabelu sa napomenama vezano za punch card, budu malo kompleksniji upiti ali rasteretis tu tabelu koja ce ti realno biti najveca tabela na sistemu
- vrsta sata ti je problem, opet ista prica, dosao sam u 7 ujutro, radno vreme mi je 9-5, morao sam da dodjem u 7 zato sto je klijent poludeo i oce da tuzi firmu za 100 miliona evra... radio sam ceo dan, donosili su mi kavu i bombone, zavrsio sam problem sledeci dan u 3 ujutro, spakovao se i krenuo kuci. To je 5-7 "nocni overtime", 9-17 "normalno vreme", 17-21 "normalni overtime", 21-03 "nocni overtime" .. jedno polhje "vrtsta sata" "won't cut it". Ti sada mozes da izbacis "vrsta sata" i da generises satnicu po nekim externim pravilima, ali sta je problem, kada firma odluci da vise nije nocno radno vreme od 21-09 nego je recimo nocni overtime 23-06, to znaci da od tog trenutka pa na dalje ti treba tako da obracunavas, ne da sada promenis konfig i da ti se poremeti obracun plata za x godina unazad...

ja bi licno ovu sihtaricu napravio kao vise tabela, jednu glavnu sa sihtarica_id, radnik_id, jednu sa sihtarica_id, od, do, tip_sata_id gde su (sihtarica_id, od) PK i onda na "punch in" popunis glavnu tabelu i prvi od, na punch out iskreiras ostale od-do rekorde u drugoj tabeli .. dodas remark u posebnu tabelu sa onim varchar-om (mozes onda ovde da ga stavis da bude i text..)

zamerke - vrsta sata:
ja volim float ali za ove stvari decimal daje mogucnost da radis zaokruzivanje po pravilima tvoje drzave

zamerke - radnik:
ovo je tabela koju trosis "non stop", ne samo za ovaj sistem vec i za celokupnu aplikaciju. Non stop ti treba korisnik_id, korisnik_username, korisnik_pass. Sve ostalo ti terba jednom u sto godina. Zato je zgodno razbiti ovu tabelu po vertikali tako da imas retko koristene podatke u drugoj tabeli (ime, prezime, jmbg, broj pasosa, broj dece, datum rodjenja, diplome, strucna sprema, bracno stanje....) tako tu tabelu olaksas ... valjda je jasno

zamerke - dnevnik
datum treba da bude datetime a ne date
to je neka log tabela koja se generalno ne koristi za rad/izvestaje, obzirom da je to log/audit tabela, zasto bi uopste dozvolio da bilo ko moze da menja bilo sta na njoj? Ako hoces da imas admin modifikacije sistema, admin ce modifikovati oni slihtara tabelu a ti u ovaj dnevnik treba da upises "admin menjao X u Y zbog Z" .. tako da onda dnevnik tabela treba da bude nesto opsirnija

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

samo jos jedan dodatak, pa se bacam na ispravljanje...

razmišljao sam o obradi podataka iz tabele dnevnik, ako kroz app obradujem te podatke onda moram da se brinem o zadnjem unosu koji sam procitao i zadnjem koji sam zapisao..., ali koliko vidim ovaj posao bi mogli obavljati triggeri... je li OK prepustiti to triggerima??

pa teoretski bi mogao da imas sp koji se aktivira na izlaz iz kancelarijei koji popuni sve to... ja nisam veliki fan tog resenja ali je validno.. problematican deo tu je sto se ta obrada radi po pravilima koja se menjaju, da li ces radije da menjas to u bazi ili u aplikaciji... na tebi je ... mysql stored procedure su meni smor, debagiranje je izmedju nemoguceg do pateticnog, sintaksa je sakata, fali ovaj i onaj feature ... sve u svemu ja uvek resavam to bez sp, cak i kad nije mysql u pitanju, sa mysql-om gledam da ih izbegavam koliko god mogu

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ispravljeno prema uputama :)

i još nešto...ako odmah računamo cijenu sati i upisujemo je u tabeli sihtarica_detalji pored vremenskog slota, to bi rijesilo problem proračuna kada dođe do promjene parametara??

pogledacu ujutro kad se naspavam, najzad vreme za krevet posle 70tak sati na nogama



teoretski da, pitanje je samo kako ces organizovati taj deo date posto ti mozes danas da imas 10 ulaza i 10 izlaza, 1 ulaz i 1 izlaz ili 10 ulaza i 9 izlaza ili 1 ulaz i nijedan izlaz ... cak mozes da imas nijedan ulaz a jedan izlaz tako da moras da vidis kada/gde/kako ces da radis update...

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

i dalje mi se ne svidja :) no vec je mnogo bolje

* tip_sata
sta ti je sad ova tabela? tip_sata tabela po meni treba da bude "konfig" tabela, dakle da ima

tip_sata_id (int)
aktuelno (enum:jeste|nije)
naziv (char)
pocinje (time)
zavrsava (time)
index_cene (decimal)
vikend (enum:da|ne) -- ovde bi moglo cak da bude pon(enum), uto(enum)... sub(enum), ned(enum) ali moze i ovako
datum_aktivacije (datetime)

i to je sve. I to ti je konfig tabela, u njoj ti za svaki tip sata pise kad pocinje, kad se zavrsava i index cene. npr:

1, nije, "normalan sat ", 07:00.00, 14:59.59, 1.0, ne, 01.01.1945
2, jeste, "normalan sat ", 09:00.00, 16:59.59, 1.0, ne, 01.01.2000
3, jeste, "nocni overtime ", 00:00.00, 08:59.59, 2.0, ne, 01.01.2000
4, jeste, "nocni overtime ", 21:00.00, 23:59.59, 2.0, ne, 01.01.2000
5, jeste, "obican overtime ", 17:00.00, 20:59.59, 1.5, ne, 01.01.2000
6, jeste, "vikend overtime ", 00:00.00, 23:59.59, 3.0, da, 01.01.2000

onda imas zasebnu tabelu gde imas "vrednost sata" i gde cuvas promene u ceni sata kroz vreme .. a pravu cenu sata racunas kao trenutnu cenu sata u toj tabeli * index_cene iz tip_sata

onda ti sihtarica detalji ima smisla. Ti si nakrcao sadrzaj cele tabele u jedan rekord trenutno + sta ce ti radnik_id u tip_sata? eventualno tip_sata moze da ima radnik_TYPE_id, pa da razlicit tip radnika ima razlicite indexe i razlicito da mu se racuna overtime, tako da recimo imas neki "prosecan sat" koji kosta recimo 50$ pa sljaker ima index za normalan sat 0.5, manager ima index za normalan sat 1.0, sef otseka ima index 2 a dba ima index 5.0 na primer .. mada je to redak slucaj i tako se radi uglavnom samo po drzavnim firmama gde se plata dobija po ceni radnog sata koja je ista za sve, u normalnim firmama ti dogovaras tu cenu individualno tako da ti za obracun treba koliko ima sati (izmnozeno sa indexima za tip sata) a onda se to pomnozi sa dogovorenom cenom sata "za tebe"

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Evo me, nisam stigao odgovoriti zbog posla...

izmijenio sam po uputama, ali i nesto na svoju ruku...

izostavio sam kolonu index_cijene, i dodao sam kolonu dan_u_sedmici, tako ne moramo imati vise kolona, a znat cemo koji je dan...

napravio sam novu tabelu radnik_tip_sata gdje cu imati cijenu sata,a takoder i istoriju satnice... (ovdje bi mogle biti, kao sto si rekao i kategorija radnika)

ipak sam se odlucio da odmah racunam cijenu sata u tabeli sihtarica_detalji... jer bi stalno racunanje uzimalo puno vremena...