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

Malo filozofiranje oko upisa stavke u bazu

[es] :: Baze podataka :: Malo filozofiranje oko upisa stavke u bazu

[ Pregleda: 3554 | Odgovora: 11 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Neznalica_sa_ugla
split

Član broj: 83282
Poruke: 390
*.st.cable.xnet.hr.



Profil

icon Malo filozofiranje oko upisa stavke u bazu04.01.2011. u 21:13 - pre 161 meseci
Da ukratko ispričam o čemu se radi , pa bih molio vaše iskustvo i kako Vi to radite .
Treba da se u bazu upišu neki podaci , recimo o osobi (object) (Mislim na relacijske baze ne na objektne , mysql , MsSql , ... )
Kada postavljem vrijednosti na objek , već mi treba id tog upisa . Ok pročitam iz tablice najveci broj , dodam 1 i nastavim unositi podatke ,i to poslije sve upišem u bazu. Gde je tu proble ??? U ovome , osoba A stvara osobu uzme Id , i puni ga , u međuvremenu dolazi osoba B i ona uzima id , na žalost isti koji ima osoba A , popuni podtke , snima (prije nego osoba A) i kada snima osoba A baza satare podatke osobe B ili prijavi grešku .
neki od problema:
1) Nemoguće je napraviti podatke za osobu bez uzetog id , jer je to prefiks , nekih podataka.
2) Zaključevalje baze , dok radi osoba A da osoba B nemože uzeti id , nije logičn ( osoba A otišla na raučak ) i blokirala bih rad celog sustava. Isto onemogućilo bih rad svim osobama koje rade poslije osobe A , dok ona ne završi posao .
3) Naknadna izmena id je komlicirana i proktično bih trebalo unositi sve podatke iznova .
Molim komentar i kako vi to rješavate , Hvala ( Ja ima jedan dosta složen algoritam , sa slucajnim brojevima , ali mi izgleda robusno i komlikovano , pogotovo što moram svaki id , vući kroz tu metodu i po nekoliko puta radi provera , pa ako su svi uslovi ispunjeni uzima id , ) Nadam se da može jednostavnije .
 
Odgovor na temu

IdeaR
BiH

Član broj: 11048
Poruke: 126
*.PPPoE-686.sa.bih.net.ba.



+2 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 10:34 - pre 161 meseci
Autoincrement na bazi?
 
Odgovor na temu

Neznalica_sa_ugla
split

Član broj: 83282
Poruke: 390
*.st.cable.xnet.hr.



Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 11:40 - pre 161 meseci
Mana tog pristupa je da broj (id) treba prije upisa , Autoincrement se dodjeli kada se upisuje u bazu. Moralo bi se i predvidjeti da sve baze nemaju Autoincrement . Naravno ukoliko se prije uzme broj , a stranka odustane od upisa , taj broj mora ostati na raspolaganju . Kosi se sa
1) Nemoguće je napraviti podatke za osobu bez uzetog id , jer je to prefiks , nekih podataka
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 11:57 - pre 161 meseci
Osnovni problem je:
Citat:
Neznalica_sa_ugla:
1) Nemoguće je napraviti podatke za osobu bez uzetog id , jer je to prefiks , nekih podataka.


Ovo predstavlja loš dizajn.

Postoji nekoliko načina da se ovo prevaziđe:

1 Autoincrement polje (u bazama koje to podržavaju). U ovom slučaju potrebno je upisati "default" slog u bazu (znači u polja koja su not null upisati neku default vrednost, u ostala null), onda uneti ostale podatke na ekranu, pa onda uraditi update sloga sa datim ID. Prilikom inserta, može se dobiti nazad autoincrement ID (zaboravio sam tačno sintaksu koja vraća vrednost autoincrementa kod inserta).

2. Kod baza koje nemaju autincrement polja, kao Oracle, koriste se sekvence - select mysequence.nextval into myID from dual

3. ID se uzima iz pomoćne tabele u koju je upisan ili poslednji dodedljeni ID ili prvi slobodni. U ovom slučaju se na početku transakcije na kratko zaključava samo ovaj jedan slog dok se vrednost ID-a inkrementira, onda se commit-uje inkrementacija, a onda se sa dobijenim ID-om popunjava ulazna forma.
 
Odgovor na temu

Neznalica_sa_ugla
split

Član broj: 83282
Poruke: 390
*.st.cable.xnet.hr.



Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 13:41 - pre 161 meseci

3. ID se uzima iz pomoćne tabele u koju je upisan ili poslednji dodedljeni ID ili prvi slobodni. U ovom slučaju se na početku transakcije na kratko zaključava samo ovaj jedan slog dok se vrednost ID-a inkrementira, onda se commit-uje inkrementacija, a onda se sa dobijenim ID-om popunjava ulazna forma.

Mogu se složiti da je ovo ne loš primjer , ali i on ima nedostataka .Osoba koja je "uzela broj" (recimo) padne joj mreža nije završila posao , ako je ista u bazu upisano , ( nije kompletni i koko izbrisati , osim ručni ) U konačnici dobili bi bazi sa polovičnim zapisima , ali zauzetim brojevima ( neiskorištenim ) .
Oprostite ja ne želim svakome naći zamerku , samo pokušavam naći najbolju mogućnost, a u tome želim da učestuju i ostali .


A što se tiče dizajne same baze , ovde je nebitno , zašto je napravljeno ovako kako je . Postojali su razlozi za to da se id umetne u neke podatke. Sama Normalizacije baze je je ok, BCNF (mada su neki ključevi u samin podacima, to progledajmo kroz prste)
 
Odgovor na temu

IdeaR
BiH

Član broj: 11048
Poruke: 126
89.146.184.*



+2 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 18:36 - pre 161 meseci
Citat:
Neznalica_sa_ugla: Mana tog pristupa je da broj (id) treba prije upisa , Autoincrement se dodjeli kada se upisuje u bazu. Moralo bi se i predvidjeti da sve baze nemaju Autoincrement . Naravno ukoliko se prije uzme broj , a stranka odustane od upisa , taj broj mora ostati na raspolaganju . Kosi se sa
1) Nemoguće je napraviti podatke za osobu bez uzetog id , jer je to prefiks , nekih podataka


Da li taj podatak (id) ima neko značenje?
 
Odgovor na temu

zoranix
Software Architect
IS MicroCore
Knjaževac

Član broj: 243111
Poruke: 162
*.dynamic.isp.telekom.rs.

Sajt: www.micro.co.rs


+36 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.01.2011. u 21:24 - pre 161 meseci
Ako sam dobro razumeo ID treba da ima neprekidan sled, da li je tako?

Ako je tako skvencama se ne rešava problem u potpunosti. Svaka sekvenca se odvija u izolovanoj transakciji, što u ovom slučaju pravi problem, jer kada transakcija "pukne" (nisu bitni razlozi...), konkuretna transakcija, dobivši naredni broj iz generatora sekvenci, upisuje slog i ostaje "šupljina" u sledu, sa ID-om koji je "pukao". Kako rešiti problem?

Zavisi od tabele. Ukoliko nema zavisnih kolona od primarnih, alternativnih i stranih ključeva i ukoliko neka od kolona nije "REQUIRED", onda predlažem da čim zgrabiš sekvencu sa "SELECT generator_sekvenci.nextval() into ID", upiši slog u tabelu sa tim ID-om sa svim ostalim kolonama koje možeš u datom trenutku da popuniš. Naravno pre toga započni transakciju i nakon upisa uradi odmah COMMIT. Time si obezbedio sled ID-a, a ksnije uradi update ostalih kolona, ako tabela dozvoljava ovakav tretman. U toku trajanja transakcije garantovano štitiš dobijeni ID od konkurentske dodele, barem je tako na većini baza (recimo PostgreSQL...) i ne zadržavaš ostale kratkim izvođenjem transakcije.

Ovakvih slučajeva ima puno u praksi, recimo kod dodele broja KEPU knjige, gde ne sme da se ostavljaju nikakve šupljine u rednim brojevima. Jedino moraš biti siguran da ovo radiš nakon "klika" na "OK" dugme na formi, kada je sve gotovo i kada se korisnik definitivno opredelio za upis sloga i nema mogućnost da odustane. Samo trajanje transakcije se sastoji samo od uzimanja sekvence i upisa sloga i ako se dogodi nešto nepredviđeno može se desiti i ovde narušavanje sleda, što je veoma mala verovatnoća.

Totalna zaštita sleda ID je moguća ako baza podržava zaključavanje tabela (neke ovo ne podržavaju, pa treba videti u dokumentaciji...). U tom slučaju si s programesrske strane opušteniji:
1. Pokreneš transakciju;
2. Pokušaš da zakljjučaš tabelu ekskluzivno, i ako ne uspeš vrtiš se u petlji dok ne uspeš. Ovo je momenat kada je već neko drugi zaključao tabelu iz istih razloga i ti ga čekaš u petlji dok on ne završi posao. Ovde je potrebno obezbediti kratko trajanje transakcije kako bi rad bio manje-više normalan (kod unosa podataka se to neće primetiti puno, ali kod masovnog insertovanja hoće i te kako).
3. Uspelo je zaključavanje, sada je tabela samo tvoja i ti insertuješ samo neophodne podatke u kolonama, čije obezbeđivanje ne traži puno vremena i koje si obavezan da imaš prilikom izvođenja INSERT naredbe, sa ID-om iz sekvenc-generatora.
4. Upis je uspešan, radiš COMMIT, ako nije saopštavaš grešku i radiš ROLLBACK.
5. Ažuriraš preostale kolone sa UPDATE sa ID-om iz sekvence koji si koristio kod INSERT-a.

Ovaj poslednji scenario garantovano ne pravi "rupice" u sledu brojeva i ja ga često koristim, a verujem da će i tebi koristiti.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.dynamic.isp.telekom.rs.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu06.01.2011. u 06:45 - pre 161 meseci
Pogledaj tekst na linku - high-low strategy.
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

Neznalica_sa_ugla
split

Član broj: 83282
Poruke: 390
*.st.cable.xnet.hr.



Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu13.01.2011. u 19:05 - pre 160 meseci
Hvala svima na diskusiji. Mene je ovdje više zanimoa problem i kako ga vi rješavate , što se tuče ključa , ja sam uvjek za ' prirodni ' ključ ako je to moguće , a tek onda za neke autonamber , koje nastojim izbjeći.Ovdje mi je zorix-ovo gledanje na stvar blisko i logiično , ,nažalost nema valjda savršenog pristupa.Neko je spomeni vođenje knjiga. JA ovako rješavam stvar dosta trapavo ali za sada nisam imao problema od kada sam prešao na ovaj recept .
1 )napravi slučajni broj u rasponu veličine id ( koji uvek uzmem velik 9- 14 cifri , tipa je ncvar
2) provjerim da li se taj koristi da -> korak 1. ne -3.
3) provjerim da li je netko već 'izvukao taj broj u polju aktivni id da -1. ne -4.
4) upisujem taj broj u polje brojeva pot- id
5) sa ovim id pustim klienta da radi i završi cijeli upis , kada završio i snima ->7 , usledio je neki prekid ili odiustao ili lijenčina otišla s posla ->6
6) poništavam taj broj iz polja ( i novi pokušaj ide iz početka , ovde vreme zavisi da li je web ili samostojeća app) gubljenje broja ,nikakva šteta
7) upis u bazu ,sa kratkim vremenom ( svakao je zaključan zapis kojega se upisuje )

ako je knjigovodsveni dok onda vrlo lako prenumeriram (kpi knjiga primitaka i izdataka i ako je to dozvoljeno ) složeno po datumima tako kada se knjiga isprinta , ima uredne redne brojeve i datume .

Znam biće zamjerki , ali ovo radi pouzdano , al da je davež jeste . Al kako imam gotove metode sdamo zakačim u svaki novi projekt , na žalost u zadnje vreme malo projekata ....

3 i 4 se odvijaju u jednom tredu i postoji mali kritični osječak da se nebi dogodilo da je neko izvukao broj ali još nije u polju i dobije se problem .Znači dok neko upisuje u polje , drugi ga nemože gledati , obrada tog polja zbog broja članiove (2-4 ) veoma je brza )


 
Odgovor na temu

Ivan452
student

Član broj: 213419
Poruke: 28
*.dynamic.isp.telekom.rs.



+2 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu03.02.2011. u 19:32 - pre 160 meseci
Prvo:
Da pravis kljuc kao random vrednost i onda proveravas da li je unet?
Veoma los pristup.
Sta ce se desiti kada imas 100 000 slogova.
1 000 000?
Sta ce biti ako ti random funkcija 10x za redom generise vrednost koja je vec uneta...

Ovo ti sa jedne strane usporava sam rad sa bazom a sa druge strane unosi nepotrebnu funkcionalnost u program.
Iskreno, ovo mi deluje kao da imas neki propust u samom dizajnu modela baze, cim moras to da radis.

Drugo:
Ovo sto ti radis nema nikakve razlike od autoInkrementa.
Generalno kljucevi ti se mogu podeliti na 2 grupe:
- surogat kljucevi (autoinkrement, ovo sto ti radis, GUID) i sl. To su kljucevi koji ne nose nikakvo znacenje o slogu (dobro autoInkrement nosi malo znacenje ali ipak spada u ovu grupu).
- druga grupa su ti kompleksni kljucevi, tj kompozitni. Kada spoljni kljucevi tabela koje ukljucuje ulaze u primarni kljuc. I na taj tacin nose znacenje.

Najbolje bi bilo ako mozes da okacis model baze pa da se iskomentarise.
 
Odgovor na temu

Zoran.Eremija
Zoran Eremija
SYSTEM ANALYST
Freelancer
Beograd

Član broj: 251342
Poruke: 855
..106.109.adsl.dyn.beotel.net.

Sajt: zoraneremija.wix.com/erem..


+47 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu03.02.2011. u 22:27 - pre 160 meseci
Slozio bih se sa komentarom kolege @Ivan452.

S time sto bih dodao i trecu varijatnu, a to je kreiranje govoreceg ID broja (PartnerID) koji bi nastao iz najmanje 2 atributa od kojih prvi govori o tome na kojoj instanci je nastala n-torka, a drugi je redni broj po toj instanci. U slucaju velikog broja zapisa moze se uvesti i treci atribut Godina.



Ovim nacinom bi se razresio problem konkurentnog rada, i izbegao piramidalnii rast inkrementalnog ID-a
Prikačeni fajlovi
 
Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427



+19 Profil

icon Re: Malo filozofiranje oko upisa stavke u bazu05.02.2011. u 23:12 - pre 159 meseci
@Neznalica_sa_ugla: Može li se znati razlog za uzimanje ID-a na samom početku unosa podataka?
Ako nije baš neophodno raditi na taj način (a u najvećem broju slučajeva i nije) onda koristi pomoćnu tabelu u kojoj čuvaš prvi sledeći ID i uzimaj ga u momentu upisa sloga u bazu. Kod višekorisničkog rada sistem traženja najvećeg i uvećanje za 1 teoretski može dovesti do dupliranja ID-a.
 
Odgovor na temu

[es] :: Baze podataka :: Malo filozofiranje oko upisa stavke u bazu

[ Pregleda: 3554 | Odgovora: 11 ] > FB > Twit

Postavi temu Odgovori

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