Brisanje bilo cega je namerno maksimalno otezano. Sastanak ne mozete jednostavno obrisati, kao da ga nije bilo, a da vec imate diskusije, odluke, prisustvo. Satanak je lako obrisati sve dok mu ne unesete dnevni red. Tacku dnevnog reda je lako obrisati dok ne unesete diskusiju ili odluku, i to samo pod uslovom da je to poslednja tacka. Ako malo pogledate tabele, videcete da skoro svuda postoji kolona Seq i SeqPrev mislim. Seq = sekvenca, i cuva redne brojeve stavki. Zbog sakrivenih indeksa, FK (relacije medju tabelama) i ponekih Validation Rules, ne moze se tek tako brisati. Razlog - Getsbi je savrseno objasnio:
Citat:
Brisanje tačke dnevnog reda bi možda imalo smisla jer se na sastanku može odlučiti da se tačka skine s dnevnog reda zbog nekih neispunjenih uslova. Konačno, dnevni red se potvrđuje na samo sastanku. Mada bih i ovo radije rešio novim poljem umesto brisanjem. Brisanje celog sastanka je već sporna stvar. To je događaj koji se odigrava u realnosti i nebi trebalo da se kasnije (nakon verifikacije otpočinjanja) negira njegovo postojanje. Nešto slično kao proknjiženi dokumenti. Dokument se stornira (radi eventualne ispravke ili nekog drugog razloga) ali se ne može negirati da je on ranije unesen u sistem.
A zasto bi i brisali? Jedni razlog, u ovom momentu, jeste testiranje programa iz zelja da se posle nekoliko primera na brzaka ocisti baza, da bi se probali novi primeri. U realnom zivotu, situacija je drugacija. Umesto brisanja bolje je 'skinuti tacku s dnevnog reda', ali ne bukvalnim brisanjem, nego oznacavanjem tacke kao 'skinuta'. To resenje nam zahteva uvodjenje pojma 'status tacke dnevnog reda'. Znaci, ako smo imali razlog da tacku stavimo na dnevni red, OK je da je skinemo, ali o tome mora ostati neki trag. Ista logika vazi za bilo koju vrstu poslovnog dokumenta. Zamislite da posle godinu dana jednostavno obrisete fakturu i sve stavke na fakturi, koristci CASCADE DELETE ili nesto slicno. Katastrofa. Iz tog razloga su CASCADE DELETE i CASCADE UPDATE veoma opasne opcoje i NE TREBE ih koristiti, ukoliko nemate jako dobar razlog. Ukoliko ne razumete i ne bavite se promenema stanja (statusa) entiteta, onda je bolje reci NIKAD ne korististiti CACSADE DELETE/UPDATE.
Modeliranje promene statusa nije lako, ne uci se u skoli, za sada, a mozda ce u naradnih 5-10 godina i da se uci. Razlog je sto je to nova oblast. Za sada sam video dve knjige koje to tek pominju, bez neke razrade (Applied Mathematics for Database professionals, de Haan, Koopelars, 2007 i Database Design and Relatioanl Thery (Normal Forms &All That Jazz) C.J Date, 2012 . Postoji i treca knjiga gde je problem razradjen, a da autor verovatno nije ni svestan koliko je veliki korak ucinio (Defensive Database programming, Alex Kuznetsov, 2010). Postoji i nekoliko clanaka, autori J.Celko i A.Kuznetsov, na SimpleTalk.com i SQLCentral.COM. I to je sve. I naravno dosadni Zidar, koji vec dve godine pokusava nesto od ovga da provuce kroz EliteSecurity forum. Poceli smo sa pracenjem zaduzivanja osnovnih sredstava, pa se nesto od ovoga potkralo u investicionom projektima (promena procenta PDV, a pokusali smo na situacijama pa odustali), pa evo sad pominjemo ovde. Onako kako je radjeno u pracenju osnovnih sredstava, mnogo je zakomplikovano. Tacke dnevnog reda se prate na mnogo jednostavniji nacin, par FK i jedna-dve Validation Rules.
Uglavnom, ko moze da korsiti program as-is (ovakakv kakav je), ili uz male ispravke - izvolite i srecno. Ko hoce da analizira resenja i mozda nauci nesto novo - jos bolje.
