Nije to suvisno samo u danasnje vreme, vec bilo kada ;-)
Prema dizajnu baze ako podvrsta treba imati informacije o vrsti, onda je pitanje selektiranja iz baze ili pitanje klientske aplikacije da konkatenira informacije vrste u podvrstu.

Jel ti ovo treba da prepravljas ili samo teoretises?

To je na neki nacin stvar ukusa ili navike. Kod savremenih baza je zaista nebitno koliko imas tabela jer je sve povezano. Kod starijih varijanti, nekad ima razloga da se stavi i vise podataka nego sto bi trebalo. I pitanje kakvi se izvestaji prave.

Ne teoretisem. Vec sam jednom portovao iz fox-pro-a u access kao back end. Kada sam to radio nisam imao vremena da se pozabavim strukturom. Vecim delom sam se oslanjao na vec postojecu arhitekturu, sve sto sam menjao je bilo on the fly. Sada sam napokon ugrabio vremena pa portujem iz access (kako lepa hierarhija :)) na SQL server i MSDE. Pa reko sad, kad vec pravim da se resim svih starih briga. Ovo mi je bitno jer nije ipak samo navika u pitanju. Imam jednu tabelu gde imam i do 250.000 slogova i to u jednoj organizaciji. Organizacija ima 700 a u buducnosti mozda i vise hiljada. Ako bi zadrzao onakvu strukturu gde se u podvrsti neke sifre nalazi i sifra, a recimo sifra sama zauzima 2 bajta, onda je ocigledno da ce to biti 2 * 250.000 * >700 bajtova vise i to samo u jednoj tabeli u jednoj godini.

Cesto sam morao da objasnjavam zasto sam nesto menjao kada sam prepravljao bazu. Pa se onda nekad i sam zabunim i mislim da sam pogresio a znam da je ispravan metod. Uglavnom vec se odlucim kako cu ali volim da pitam da cujem tudje protiv argumente.

jednokratno u siframa podvrste izbaci deo koji je u stvari sifra vrste i skrati polje za toliko i to je to. U foxprou se radi tako jer je to drugacija vrsta baze pa koriscenje primarnih kljuceva koji se sastoje od vise polja moze da ude problematicno u nekim situacijama. Tako fox baza radi brze.

Kod savremenijih baza o tome ne mora da se vodi racuna tako da mozes slobodno da iz podvrsta izbacis sifru vrste ali ne zaboravi da ti je onda primarni kljuc sifraVrste + sifaPodvrste

Ako je visak ova dva bajta, skrati, mada u danasnje vreme ne bi o tome trebao brinuti. A s druge strane, verovatno ces morati imati vezu vrsta->podvrsta, i za to kreirati neku tabelu. Ovako to vec imas pa ces ustedeti vise od dva bajta.

Nije mi namera nikog ni da branim ni da napadam. Samo ne znam kakva je aplikacija ni kakvi se izvestaji traze.

Ovo može pod uslovom da postoji samo jedan nivo podvrsta. Ako je u pitanju razgranatija struktura, morao bi da daje jedinstvene šifre vrstama, a u jednom polju da drži šifru nadvrste.

Ti hoces da kazes ako bi se prihvatio takve strukture sifri onda bi mogao da izbacim sifruVrste jer sve je u sifriPodvrste. Well, to mozda nije lose ali svrha sifraVrste je da se zna u kojoj vrsti pripada neka podvrsta posla. Pa sta onda da radim kad mi treba grupisanje po vrsti posla u podvrstama(String operation)?




Nisam odma skontao. Da ne radis mozda u fox-pro-u ili clipper-u? Tamo su bili critical izvestaji pa su se onda mnoge tabele prilagodjavale za laksi rad sa izvlacenjem podataka. Otuda i ovakve strukture kao sto sam opisao. (znam iz iskustva, doduse tudjeg :)) Podatke je dosta lako preko SQL-a izvuci tako da nema potrebe prilagodjavat dizajn baze za izvestaje.

Koristim clipper sto ne znaci da ne poznajem i druge stvari, SQL mi se svideo odma.

Clipper ili FoxPro koristi DBF datoteke. I obicno je moralo da se dobro optimizuje da bi brzo radilo. Sa savremenim alatim to vise nije imprativ jer su baze bolje, racunari brzi.

I jos jedna stvar. Pokazao si strukturu samo jedne tabele. Sta je sa ostalim, koliko ih ima. Kad sagledas sve onda ces moci da napravis normalizaciju. Ovako je tesko nesto reci. Kritikovati ili hvaliti.

Ma nisam ja hteo da omalazavam clipper ili fox-pro niti one koji u njima rade. Za razliku od nekih koji odmah se zgroze na rec clipper, fox-pro, dbase ili bilo sta sto nije moderno i ima GUI. Ja sam od onih koji su imali malo dodirnih tacaka sa njima i znam otprilike kako rade. Iskreno se i divim starim programerima jer je cinjenica da je trebalo mnogo vise rada pod njima nego u danasnjim alatima za istu stvar.



Nisu ostale toliko bitne. Manje-vise sve je otprilike ista struktura. Interesovalo me je samo da li je ono suvisno ili ne.

A tabela...
ima ih dosta...

Naprotiv, izbaci sifru vrste iz sifara u polju sifrapodvrste a polej sifravrste ostavi. Tako dobijas strukturu tabele kako se radi skolski (naravno pod uslovom da se ne radi o hijerarhijskom sifarniku sa dubinom strukutre N gde se stvari dosta komplikuju, ali cini mi se da nije takav slucaj)

Bez brige, razumemo se. Koliko lepse izgleda toliko je komplikovanije. Secam se kursa od pre 15 godine, onda smo poceli sa Oraclom. I neko pita predavaca "koliko ovo povecava produktivnost?" Odgovor je bio "koliko zasucete rukave". I to je to. Jedna vezba za oracle forms se zvala "create and run form in 60 seconds" To me je odusevilo pa sam napravio razvojni alat za clipper, default forma za manje od minut. I za izvestaje slicno.

E, sad. Ako hoces nesto da menjas onda zasuci rukave, pa kuckaj ili klikci dok ne radi kako treba. I to je ono sto traje.

Ako hoces lepsi primer. Drugar "otkrio" access. Napravio neku formu za 5 minuta i dao u firmi da koriste. A kad je pocelo "ajde ispravi samo ovo" nastase muke. Odakle da krene kad je ovo prvi put video juce...

Pomorci kazu "hvali more, al' se drzi kopna". Jednostavno receno koristi ono sto znas i sa cim ces da napravis sve sto zamislis ili sto ti traze. Stari sistemi su bili jednostavni, do koda si dosao preko svakom editora, a kod novih prolazis kroz sve te alate da bi izmenio i najmanju sitnicu.

Nedavno se prijatelj "zapalio" za delfi. Dade mi cd, instaliram i ne znam sta cu s tim. Kad sa ga pitao "kako se ovo koristi" odgovor bese "pojma nemam ali svi ga fale da je mnogo dobar".

Stvarno se nismo razumeli :)
Sto se tice N, u pravi si nije takav slucaj




Upravo to i ja govorim. Vecina gleda "modu". I dosta njih u napred zna sta valja a sta ne a da pre toga nisu ni spoznali problematiku. Ode ja off topic...

Uglavnom, hvala na kometarima