Modelovanje BP SS

Modelovanje BP SS 20.01.2013. u 19:31 · pre 167 meseci #1

Poštovani,

Imam problema sa modelovanjem baze podataka studentske službe. U pitanju je više skolski primer. Nedoumica se odnosi na obeležja koja bi možda postavio kao entitete. Evo o čemu se radi..

Pretpostavimo da se za svakog studenta prati "status_studenta" i "način_finansiranja". Ti bi se podaci mogli prostirati na više tabela (hipotetički pretpostavimo tabele prijavaStudenta i UpisStudentaUskolskgGodinu ). Za način finansiranja bi se pratilo da li je student npr. na samofinansiranje, na budžetu ili mozda sufinansiranju. Za status_studenta bi se pratilo da li je student npr. redovan, vandredan, student sa statusom mirovanja, ponovac, ispisan, diplomiran ili mozda sa STATUSOM "zabrana izlaska na ispit". Moje pitanje jeste, Ima li smisla ova obeležja studenta (status_studenta i nacin_finansiranja) predstaviti posebnim ENTITETIMA koji bi potom prostirali vrednosti primarnog kljuca na tabele PrijavaStudenta i UpisStudentaUskolskgGodinu. Tabela UpisStudentaUskolskgGodinu bi predstavljala bazu za praćenje toka studija studenta. Objasnio bi samo da tabela "UpisStudentaUskolskgGodinu " sadrži informacije o studentima upisanim u školskoj godini, bez obzira na godinu studija (da li student ponavlja istu godinu ili možda upisuje narednu). Primarni ključ te tabele će biti sastavljen od foreign key obeležja "brojDosijea" i "skolskaGodina".

Sa dva modela sam pokušao da predstavim moje viđenje problema. Prvi, tačnije, počeetni model će biti predstavljen obeležjima "status_studenta" i "način_finansiranja" implenentiranih u tabelu "UpisStudentaUskolskgGodinu ", dok će u drugom modelu pomenuta obeležja biti predstavljena posebnim tabelama. Još jednom, mene interesuje samo ispiravnost modela. Da li je pametnije obeležja "status_studenta" i "način_finansiranja" predstaviti samo kao obeležja u tabelama UpisStudentaUskolskgGodinu i prijavaStudenta, ili je pametnije njihovu prezentaciju predstaviti tabelama. Nadam se da će biti zainteresovanih da prodiskutuju o tome.

ispravkaModela.png69.93k pocetniModel.png73.4k

Re: Modelovanje BP SS 21.01.2013. u 18:48 · pre 167 meseci #2

Meni je OK za skolski zadatak. Za praksu - nije dovoljno dobro, ali ne znaci da neces naci ovakvih resenja u praksi.

Moguci problemi (ako ne razumes, ne brini, ignorisi, zadatak ce proci i bez ovoga):
Problemi su u nerazumevanj pojma "Status". Kazes

Citat:

Za status_studenta bi se pratilo da li je student npr. redovan, vandredan, student sa statusom mirovanja, ponovac, ispisan, diplomiran ili mozda sa STATUSOM "zabrana izlaska na ispit".

Osobine "Redovan","Vanredan" nisu status, to je "nacin studiranja", na isti nacin kao sto skup {"sam placa","na budzetu","delimicno placa"} predstavlja nacin finansiranja.

Status bi bio opisan recima iz skupa { "Upisan","Ispisan","U mirovanju", "Diplomirao" } Za svaki status mora se znati datum ulaska u status. Prvi status za svakog studenta bio bi "Upisan". U vecini slucajeva, student bi posle nekog vremena presao u status "Diplomirao" i to je sve. U nekim slucajevima, posle "Upisan" imali bismo status "Ispisan" ili "U mirovanju", aposle mirovanja moze "Vratio se" ili "Ispisao se". Znaci, bolje bi bilo pratiti status u posebnoj tabeli i nekkao obezbaditi da ne moze prvi status da bude "Ispisan" - ne mozes se sipisati ni diplomirati a da nisi prvo upisan.

U tvom modelu statusi su u haosu. U tabeli Student imas kolone Ispisan tinyint, ali nemas datum ispisa.Za upis imas samo GodinaUpisa. Zatim, imas StatusStudenta u tabeli UpisUSSkolskuGodinu, takodje bez datuma ulaska u status i bez ikakve istorije prethodnih statusa.

Namerno nisam pomenuo status opisan recima "zabrana izlaska na ispit". To jeste status, ali ne iste vrste kao { "Upisan","Ispisan","U mirovanju", "Diplomirao" }. Istina, moras barem biti upisan da bi ti zabranili da izadjes na ispit, ali ako si diplomirao ili si ispisan, onda zabrana izlaska na ispit nema nikakvog smisla. Dalje, zabrana izlaska na ispit, koji ispit?

Pazi, ovo su teska pitanja i nije sigurano da bi ti i profesor mnogo pomogao. Zato predlazem da uvedes posebni entitet za statuse, dva entitetea, jedan za { "Upisan","Ispisan","U mirovanju", "Diplomirao" } i drugi na nivou ispita sa bar dva stanja { "ima pravo da polaze","nema pravo da polaze" }. Tabele bi imale ovaj oblik:

StatusStudenta: {BrojINdeksa;Status ("Upisan","Ispisan","Diplomirao");DatumStatusa}
StatusISpita: {BrojIndeksa;Predmet; Status ("zapoceo", "ima pravo da polaze","prijavio","nema pravo dapolaze","polozio")} ("polozio" je valjda ciljni status za svaki ispit

)

Time ces pokazati da si barem razmisljao o ovom problemu. Kako da garantujes pravilan prelazk iz statusa u status? Moze pomocu CHECK i FK, ali to je duga prica i prevazilazi redovan skolski program. Ako bas hoces, mogu ti pokazati na forumu kako s eto radi, ali nije obavezno. To ionako ne mozes u potpunosti da pokazes na ER dijagramu - CHECK uslovi se n vide na ER dijagramu. Zato ne pominji pravilan prelazak iz statusa u status i bices OK. Ako te profesor nekim cudom to i pita, onda imas dobrog profesora. Kazi mu da bi se to uradilo programskim kodom, i verovatno ce biti srecan. Ako mu se to ne svidi, on ce verovatno znati d ati objasni kako treba da se radi, u tom slucaju profesor nie samo dobar nego je vanserisjki dobar.

Re: Modelovanje BP SS 21.01.2013. u 22:48 · pre 167 meseci #3

Zidar, hvala na iscrpnom odgovoru i odličnim komentarima.. Naravno, ja sam pogresno predstavio stvari oko statusa. To me je najvise i bunilo. Mene je u isto vreme zanimalo da li je greska ako se statusna kolona predstavi kao poseban entitet, tacnije, umesto CHECK ogranicenja da li bi bilo pametno status predstaviti tabelom, odnosno sa FK ... Dakle, da li je i jedno i drugo je moguće ili...?

Moje dalje pitanje je vezano za dole navedene tabele.
Pošto imam tabelu "skolskaGodina", da li je pametno da u okviru navedene tabele StatusStudenta ubacim i kolonu skolskagodina (StatusStudenta: {BrojINdeksa, skolskaGodina;Status ("Upisan","Ispisan","Diplomirao");DatumStatusa}) koja ce biti referenca na tabelu SkoslaGodina !? Poznato je da student više puta može da ima status mirovanja... Konkretno, u slučaju bolesti, odlaska u vojsku, trudničkog bolovanja itd... To znači da bi mu se status mogao menjati više puta u toku školske godine. Pretpostavimo da je student upisao prvu godinu studija, a da je potom podneo zahtev za zamrzavanje statusa (status mirovanja). Nakon određenog vremena, student može da iz statusa mirovanja podnese molbu za ispis sa fakulteta. Ja cu pokusati da novim modelom predstavim ono sto sam razumeo u tvom odgovoru. Mozda ce biti male izmene kod statusaIspita...

ispravkaModela_2.png73.74k

Re: Modelovanje BP SS 22.01.2013. u 00:36 · pre 167 meseci #4

Predlazem ti da izbacis tabelu StudentPohadjaSkolskuGodinu i vratis tabelu upis iz proslog posta

Student vise puta moze da menja status u toku godine - znaci potrebna je i tabela PromenaStatusa sa poljima:

IDPromenaStatusa PK
BrojIndeksa FK
StatusID Fk (novi status, stari se vec zna na osnovu prethodne promene)
DatumPromene
RazlogPromene

U tabelu SkolskaGodina mozes da ubacis jos dva date polja Od i Do da bi
na osnovu datuma promene mogao da nadjes na koju se skolsku godinu promena odnosi

Student moze da promeni godinu studija samo jednom godisnje, prilikom upisa, pa ti predlazem da vratis tabelu Upis iz proslog posta (iz nje naravno izbaci polje status, ti podaci se vec vode u tabeli PromenaStatusa)

Ako student menja nacin finansiranja samo prilikom upisa godine onda i to polje ostavi u tabeli Upis, a ako moze vise puta u toku godine onda na slican nacin napravi i tabelu PromenaNacinaFinansiranja

Re: Modelovanje BP SS 24.01.2013. u 20:03 · pre 167 meseci #5

Dexxxl je dao dobar savet generalno, ali je implementacija losa.
Dobro:

Citat:

Student vise puta moze da menja status u toku godine - znaci potrebna je i tabela PromenaStatusa

Pracenje statusa je uvek bolje raditi u zasebnoj tabeli. Pod uslovom da je tabela dobro napravljena. U stvari radi se o dve tabele. Videcemo kako i zasto.
Recenicu sam prekinuo pre nego sto preporuci strukturu. Evo zasto. Napravicu tabelu onako kako je predlozeno:

Code:

IF Object_ID('tempdb..#PromenaStatusa') IS NOT NULL DROp TABLE #PromenaStatusa
;
CREATE TABLE #PromenaStatusa
(
IDpromeneStatusa int PRIMARY KEY
, BrojIndeksa   int NOT NULL
, SkolskaGodina int NOT NULL
, StatusStudents varchar(15) NOT NULL
, DatumPromene datetime NOT NULL
, razlogPromene varchar(15) NULL
)

INSERT INTO #PromenaStatusa
SELECT 1, 270, 78, 'Upisao godinu', '19781001', NULL
UNION
SELECT 2, 270, 78, 'Diplomirao', '19850625', NULL
;
SELECT * FROM #PromenaStatusa
;
IDpromeneStatusa BrojIndeksa SkolskaGodina StatusStudents  DatumPromene            razlogPromene
---------------- ----------- ------------- --------------- ----------------------- ---------------
               1         270            78 Upisao godinu   1978-10-01 00:00:00.000 NULL
               2         270            78 Diplomirao      1985-06-25 00:00:00.000 NULL

(2 row(s) affected)

Naoko, sve je OK, covek upisao 1978 i diplomirao 1985 (tad je fakultet bio 5 godina, pa malo apsolventski, pa diplomski i eto ti 7 godina

)
Sta me sprecava da ispisem ckolegu koji je vec diplomirao, iako ispisvanje posle diplomiranja nema nikakvog smisla. (Mozda i ima, ali mi samo ilustrujemo primer) Sada cu da ispisem kolegu, i to sa pogresnim datumom (kolega je rodjen 1960, pa nije mogao da se sipise pre upisa 1978)

Code:

INSERT INTO #PromenaStatusa
SELECT 3, 270, 78, 'Ispisan', '19581001', 'Greska!'
;
SELECT * FROM #PromenaStatusa
;
IDpromeneStatusa BrojIndeksa SkolskaGodina StatusStudents  DatumPromene            razlogPromene
---------------- ----------- ------------- --------------- ----------------------- ---------------
               1         270            78 Upisao godinu   1978-10-01 00:00:00.000 NULL
               2         270            78 Diplomirao      1985-06-25 00:00:00.000 NULL
               3         270            78 Ispisan         1958-10-01 00:00:00.000 Greska!

(3 row(s) affected)

Podaci u tabeli nemaju bas mnogo smisla. Greske su moguce i tesko ih je uociti, a jos teze spreciti. Gde je pravo resenje? Zaboravimo na trenutak na tabele i pozabavimo se samim statusima. Ako definisemo nekoliko statusa: {Upisan, Ispisan, Pauzira, Aktiviran, Diplomirao}, potrebna su nam i neka pravila o tome kako se statusi odnose jedan prema drugom. To se moze iskazati recima:
1. Student mora da bude prvo 'upisan'
2. Posle upisa, student moze da diplomira i posle toga se ne dozvoljavaju promene - 'Diplomirao' je finalni status.
3. Posle upisa, student moze da pauzira, pa da se ponovo aktivira ili ispise.
4. POsle aktiviranja moze da ponovo pauzira ili da diplomira
5. Ako se ispise, to je finalan status.
6. Ako se ponovo upise posle jednog od finalnih status, dobija novi broj indeksa i sve pocinje iznova

Kako obezbediti da se ova pravila postuju? Ni slucajno ne pokusavajte trigerima i stored procedurama - nece ici jer cete vecito menjati pravila, uvoditi nove statuse jer na pocetku niste definisali zadatak dobro. ja sam poceo sa tri status (Upisan, Pauzira, Diplomirao) pa sam dodao 'ispisan', pa sam shvatio da mi treba i 'aktiviran', ko zna do kraja posta mozda bude i vise. Da bi resili problem promene pravila, napravimo tabelu StatusiLKP

Code:

CREATE TABLE zStatusLKP ( [Status] varchar(15) PRIMARY KEY )
;
INSERT INTO zStatusLKP
SELECT 'Upisan'
UNION
SELECT 'Pauzira'
UNION
SELECT 'Re-aktiviran'
UNION
SELECT 'Ispisan'
UNION
SELECT 'Diplomirao'
;

Sad dodje glavo (prva polovina glavnog) -tabela DozvoljenePromenStatusa. pre tabele, evo mala slika o tome kako se mnjaju statusi, sve moguce promene kojih smo se do sada setili:

Sad nam treba tabela da 'zapamtimo' sliku. Ovako:

Code:

IF Object_ID('zDozvoljenePromeneStatusa') IS NOT NULL DROp TABLE zDozvoljenePromeneStatusa
;
CREATE TABLE zDozvoljenePromeneStatusa
(
Iz_Statusa varchar(15) NULL
, U_Status varchar(15) NOT NULL
)
;
ALTER TABLE zDozvoljenePromeneStatusa
ADD CONSTRAINT FK_Iz_Statusa FOREIGN KEY (Iz_Statusa) REFERENCES zStatusLKP ([Status])
;
ALTER TABLE zDozvoljenePromeneStatusa
ADD CONSTRAINT FK_U_Status FOREIGN KEY (U_Status) REFERENCES zStatusLKP ([Status])
;
-- Ovo vazi samo za MS SQL:
ALTER TABLE zDozvoljenePromeneStatusa
ADD CONSTRAINT uniq_zDozvoljenePromeneStatusa UNIQUE (Iz_Statusa,U_Status)
;

Code:

Primetite da nemao PK - to je zato sto dozvoljavamo NULL u koloni Iz_Statusa. Ali, imam UNIQUE (Iz_Statusa,U_Status) pa ce MS SQL dozvoliti samo jean red sa NULL (ORACLE i ostali rade drugacije, prihvataju vsestruke NULL vrednosti, pa kod njih treba staviti Iz_Statusa = U_Status = 'Upisan'
Da unesemo podatke u tabelu:

Code:
INSERT INTO zDozvoljenePromeneStatusa
SELECT Iz_Statusa = NULL, U_Status = 'Upisan'
UNION
SELECT Iz_Statusa = 'Upisan', U_Status = 'Ispisan'
UNION
SELECT Iz_Statusa = 'Upisan', U_Status = 'Pauzira'
UNION
SELECT Iz_Statusa = 'Upisan', U_Status = 'Diplomirao'
UNION
SELECT Iz_Statusa = 'Pauzira', U_Status = 'Ispisan'
UNION
SELECT Iz_Statusa = 'Pauzira', U_Status = 'Re-aktiviran'
UNION
SELECT Iz_Statusa = 'Re-aktiviran', U_Status = 'Pauzira'
UNION
SELECT Iz_Statusa = 'Re-aktiviran', U_Status = 'Diplomirao'
;

Sada u tabeli imamo:

Code:
SELECT * FROM zDozvoljenePromeneStatusa
;
Iz_Statusa      U_Status
--------------- ---------------
NULL            Upisan
Pauzira         Ispisan
Pauzira         Re-aktiviran
Re-aktiviran    Diplomirao
Re-aktiviran    Pauzira
Upisan          Diplomirao
Upisan          Ispisan
Upisan          Pauzira

(8 row(s) affected)

Ako hocemo da kontrolisemo prelaz iz statusa u status, tabela za pracenje statusa mora biti konstruisana na specijalni nacin. Napravite pauzu, popijte kafu, ko pusi nek zapali cigaru pre nego sto nastavimo. Sad dolazi natezi dao za razumevanje.

PromeneStatusa.png8.78k

Re: Modelovanje BP SS 24.01.2013. u 21:15 · pre 167 meseci #6

Ako smo popili kafu, odmorili se, sad idemo svezui u nove radne pobede. evo je tabela i CONSTRAINTS koji nam trebaju. Od svih constraints, samo se jedan FK moze pokazati na ER dijagramu, pa vidimo da je i ER diagramming nekompletna tehnika. Time sto ste napravili ispravan ER dijagram NISTE ZAVRSILI projaktovanje baze podataka. POtrebni su i CHECK constraints, UNIQUE, poneki AK i super-kay, kao sto cemo upravo videti:

Code:

IF Object_ID('zPromenaStatusa') IS NOT NULL DROp TABLE zPromenaStatusa
;
CREATE TABLE zPromenaStatusa
(
  BrojIndeksa   int NOT NULL
, SkolskaGodina int NOT NULL
, NoviStatus varchar(15) NOT NULL
, StariStatus varchar(15) NULL
, DatumPromene datetime NOT NULL
, DastumStarogStatusa datetime NULL
, RazlogPromene varchar(15) NULL
)
;

-- Ogranicimo promene statusa na dozvoljene kombinacije:
ALTER TABLE zPromenaStatusa
ADD CONSTRAINT FK_zPromenaStatusa_ValidTransition FOREIGN KEY (StariStatus, NoviStatus)
REFERENCES zDozvoljenePromeneStatusa  (Iz_Statusa,U_Status)
;

-- Svaka tabela treba da ima PK
ALTER TABLE zPromenaStatusa
ADD CONSTRAINT PK_zPromenaStatusa PRIMARY KEY (BrojIndeksa, SkolskaGodina, DatumPromene)
;
-- Ovim sprecavamo da se isti status unese nekoliko puta zaredom
ALTER TABLE zPromenaStatusa
ADD CONSTRAINT UNQ_zPromenaStatusa UNIQUE (BrojIndeksa, SkolskaGodina, DastumStarogStatusa)
;

-- Super key, trebace nam u sledecm koraku, PK + NoviStatus :
ALTER TABLE zPromenaStatusa
ADD CONSTRAINT SK_zPromenaStatusa UNIQUE (BrojIndeksa, SkolskaGodina, DatumPromene, NoviStatus)
;

-- Ovim garantujemo redosled - StariStatus u jednom redu mora odgovarati NoviStatus u nekom od prethodnih redova
ALTER TABLE zPromenaStatusa
ADD CONSTRAINT FK_Redosled
FOREIGN KEY (BrojIndeksa, SkolskaGodina, DastumStarogStatusa, StariStatus)
REFERENCES zPromenaStatusa (BrojIndeksa, SkolskaGodina, DatumPromene, NoviStatus)
;
-- iskoristili smo super key :-)

-- Ovim garantujemo da ce prvi red biti uvek 'Upisan'
ALTER TABLE zPromenaStatusa      -- NoviStaus = Upisan =>
ADD CONSTRAINT ck_PrviStatus_Upisan_Staro_NULL
CHECK ( NOT (NoviStatus = 'Upisan') OR (StariStatus IS NULL AND DastumStarogStatusa IS NULL ) )
;
ALTER TABLE zPromenaStatusa      -- NoviStaus = Upisan =>
ADD CONSTRAINT ck_Staro_NULL_PrviStatus_Upisan
CHECK ( NOT (StariStatus IS NULL AND DastumStarogStatusa IS NULL ) OR (NoviStatus = 'Upisan')   )
;
-- Ovim garantujemo redosled
ALTER TABLE zPromenaStatusa      -- NoviStaus = Upisan =>
ADD CONSTRAINT ck_StariDatumPreNovog
CHECK (DastumStarogStatusa<=DatumPromene)
;

Unesimo nekoliko test redova:

Code:

-- testiranmo:
-- DELETE zPromenaStatusa
SELECT * FROM zPromenaStatusa

-- Upisao se student:
INSERT INTO zPromenaStatusa
(
  BrojIndeksa, SkolskaGodina
, NoviStatus, StariStatus
, DatumPromene, DastumStarogStatusa
, RazlogPromene
)
SELECT
BrojIndeksa = 270, SkolskaGodina = 78
, NoviStatus = 'Upisan', StariStatus = NULL
, DatumPromene = '19781001', DastumStarogStatusa = NULL
, RazlogPromene  = NULL
;

-- Student diplomirao:
INSERT INTO zPromenaStatusa
(
  BrojIndeksa, SkolskaGodina
, NoviStatus, StariStatus
, DatumPromene, DastumStarogStatusa
, RazlogPromene
)
SELECT
BrojIndeksa = 270, SkolskaGodina = 78
, NoviStatus = 'Diplomirao', StariStatus = 'Upisan'
, DatumPromene = '19850625', DastumStarogStatusa = '19781001'
, RazlogPromene  = NULL
;

SELECT * FROM zPromenaStatusa
/*
BrojIndeksa SkolskaGodina NoviStatus      StariStatus     DatumPromene            DastumStarogStatusa     RazlogPromene
----------- ------------- --------------- --------------- ----------------------- ----------------------- ---------------
        270            78 Upisan          NULL            1978-10-01 00:00:00.000 NULL                    NULL
        270            78 Diplomirao      Upisan          1985-06-25 00:00:00.000 1978-10-01 00:00:00.000 NULL

(2 row(s) affected)
*/

Da probamo neke greske da napravimo:

Code:

-- Da probamo gresku, da ispisemo students  27 godina posle diplomiranja:
INSERT INTO zPromenaStatusa
(
  BrojIndeksa, SkolskaGodina
, NoviStatus, StariStatus
, DatumPromene, DastumStarogStatusa
, RazlogPromene
)
SELECT
BrojIndeksa = 270, SkolskaGodina = 78
, NoviStatus = 'Ispisan', StariStatus = 'Diplomirao'
, DatumPromene = '20130124', DastumStarogStatusa = '19850625'
, RazlogPromene  = NULL
;
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the FOREIGN KEY constraint "FK_zPromenaStatusa_ValidTransition". The conflict occurred in database "Dejan", table "dbo.zDozvoljenePromeneStatusa".
The statement has been terminated.
-- Iz statusa 'Diplomirao' ne moze se preci u 'Ispisan' jer takva kombinacija ne postoji u tabeli zDozvoljenePromeneStatusa.

Upis u tabelu zPromeneStatusa je sada prilicno komplikovana stvar i neke je gresk tesko napraviti, cak i kada se trudimo. Evo nekoliko primera.

Code:

-- Da dodamo jedn red izmedju Upisa i Diplomiranja za naseg studenta:
INSERT INTO zPromenaStatusa
(
  BrojIndeksa, SkolskaGodina
, NoviStatus, StariStatus
, DatumPromene, DastumStarogStatusa
, RazlogPromene
)
SELECT
BrojIndeksa = 270, SkolskaGodina = 78
, NoviStatus = 'Ispisan', StariStatus = 'Upisan'
, DatumPromene = '19801001', DastumStarogStatusa = '1978-10-01'
, RazlogPromene  = 'Asdfg'
;
Msg 2627, Level 14, State 1, Line 1
Violation of UNIQUE KEY constraint 'UNQ_zPromenaStatusa'. Cannot insert duplicate key in object 'dbo.zPromenaStatusa'.
The statement has been terminated.
-- Znaci, nemoguce je naknadno ddoavati promene imedju postojecih!

-- Prvi status mora bit 'Upisan' i tada StariSTatus i DastumStarogStatusa moraju biti NULL
INSERT INTO zPromenaStatusa
(
  BrojIndeksa, SkolskaGodina
, NoviStatus, StariStatus
, DatumPromene, DastumStarogStatusa
, RazlogPromene
)
SELECT
BrojIndeksa = 100, SkolskaGodina = 2005
, NoviStatus = 'ISpisan', StariStatus = NULL
, DatumPromene = '19801001', DastumStarogStatusa = NULL
, RazlogPromene  = 'Asdfg'
;
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_PrviStatus_Upisan_Staro_NULL". The conflict occurred in database "Dejan", table "dbo.zPromenaStatusa".
The statement has been terminated.

Neko ce primetiti da je u pitanju de-normalizacija. Jeste, ali je strogo kontrolisana i daje mnogo robustnije resenje.

Forum kao aplikacija na telefonu

Srodne teme