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

Primary key - isključen??? Kako je to moguće?

[es] :: Access :: Primary key - isključen??? Kako je to moguće?

Strane: 1 2

[ Pregleda: 4447 | Odgovora: 22 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

fahre72
Zenica

Član broj: 303817
Poruke: 32
31.176.148.*



Profil

icon Primary key - isključen??? Kako je to moguće?28.06.2013. u 09:12 - pre 130 meseci
Upravo mi se desilo nešto čudno.

Imam bazu koju upravo punim podacima i došao sam do nekih 1500 redova i odjednom primijetim da mi se čudno ponašaju podaci. Iznenada su nestali zadnjih 10-tak unešenih. Kad tamo u jednoj tabeli isključen primary key na autonumber polju koje mi je Id. I još uključeno Duplicates OK na tom istom polju.

I lijepo fino je baza počela da duplira podatke u toj tabeli i to od nekog 1026 počela da dodjeljuje brojeve iako se ja nalazim na 1515. Pa ako je polje autonumber, bez obzira što je tajanstveno isključen PK, zar ne bi trebalo da nastavi od najvećeg broja u toj koloni pa nadalje. I ne znam kako je uopšte moguće da se PK sam isključi. Znači sigurno je bio uključen i niko drugi ne radi na bazi osim mene.

I još nešto: u bazi imam nekih 28 tabela od kojih su mi 3 radne, ostalo su šifrarnici. E sad PK je bio isključen u još jednoj tabeli ali tu nisam imao problema da vratim PK pošto nije bilo dupliranja, dok u trećoj nije bilo problema. I još da napomenem da kontinuirano radim na razvoju baze, tako da možda ovo nije ni čudno, ali do sada mi se nije desilo.

Problem sam riješio tako što sam izbrisao duplirane podatke (sreća pa samo 10) i ponovo uključio PK na autonumber polju. i sad je sve OK.

Samo sam htio da podijelim iskustvo i da vidim da li je neko imao neko slično.
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Primary key - isključen??? Kako je to moguće?28.06.2013. u 15:38 - pre 130 meseci
Citat:
Pa ako je polje autonumber, bez obzira što je tajanstveno isključen PK, zar ne bi trebalo da nastavi od najvećeg broja u toj koloni pa nadalje.
Nema garancije da ce autonumber nastaviti gde je stao niti da ce biti unique. Problem je sto vecina ljudi veruje upravo da autonumber sam po sebi garantuje jedinstvenost pa cesto zaborave da postave PK. Najcesce se nedostatak PK na autonumber polju ne primeti jer u najvecem broju slucajeva autonumber se zaista ponasa 'kako treba' - izgleda da daje jedinstvene brojeve. "U najvecem broju slucajava" nije isto sto i "uvek". Ponekad se desi, vrlo retko, ali se desi, upravo ono sto se tebi desilo. Moguce da je doslo do korupcije baze, pa bi compact ili export u novu bazu mozda pomogao.

Najverovatnije da tvoja tabele nije ni imala PK, ali se to nije primetilo. Takodje, Access dozvoljava jos jednu besmislicu koju si i sam uocio - ako postavis PK na neko polje, ne trazi da psotavis Required = YES, mada se taj PK ispravno ponasa - ne dozvoljava NULL vrednosti.

Usput, koriscenje autonumber za PK i nije tako sjajna ideja, jedan od razloga - nepredvidljivo ponasanje autonumbera. Ako zaista nemas nista drugo, nego mora autonumber, onda imas problema sa logikom dizajna baza. U tom slucaju, problemi (raznih vrsta) ce se nastaviti jos dugo, zauvek moze se reci.
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
31.176.175.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?28.06.2013. u 20:20 - pre 130 meseci
Da bi vratio PK na autonumber polje morao sam:
1. izbrisati sve duplirane record-e
2. postaviti PK (e ovdje sam opet imao problem, nastavio ja da unosim kad ono kaže ne može, počeo mi opet uzimati vrijednosti iz sredine tabele), zbog toga sam morao još i:
3. uraditi compact

i sada je sve ok

Naravoučenije: dobro provjeriti da li su postavljeni PK u tabelama i (ovo nisam znao i do sada sam ovo radio po default-u) izbjegavati auto number polje za postavljanje PK, ako je to moguće.

I još jedno pitanje oko dizajna baza: ako imamo skup podataka koji treba unijeti u bazu i on nije uvijek isto popunjen, odnosno jednog datuma se traži da se unese jedna grupa podataka, drugi put druga grupa i tako dalje bez nekog pravila, da li je bolje sve te podatke držati u jednoj tabeli i namjerno imati puno polja sa null vrijednostima ili je bolje sve te podatke odvojiti u posebne tabele. tada imamo puno tabela ali neće biti praznih polja u tabelama. Nešto slično sam predložio za bazu praćenja mjerenja kod dijabetesa, počeću da pravim tu bazu pa se bojim da ne napravim grešku na početku.
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Primary key - isključen??? Kako je to moguće?28.06.2013. u 21:25 - pre 130 meseci
Upravo tako:"Naravoučenije: dobro provjeriti da li su postavljeni PK u tabelama i (ovo nisam znao i do sada sam ovo radio po default-u) izbjegavati auto number polje za postavljanje PK, ako je to moguće." Kad se ovo prihvati na pocetku, zivot je posle mnogo laksi.

Pitanje: "I još jedno pitanje oko dizajna baza: ako imamo skup podataka koji treba unijeti u bazu i on nije uvijek isto popunjen, odnosno jednog datuma se traži da se unese jedna grupa podataka, drugi put druga grupa i tako dalje bez nekog pravila, da li je bolje sve te podatke držati u jednoj tabeli i namjerno imati puno polja sa null vrijednostima ili je bolje sve te podatke odvojiti u posebne tabele. tada imamo puno tabela ali neće biti praznih polja u tabelama. Nešto slično sam predložio za bazu praćenja mjerenja kod dijabetesa, počeću da pravim tu bazu pa se bojim da ne napravim grešku na početku. "

Teorijski, treba vise tabela, svaka za svoj skup podataka. U praksi, sve zavisi, kako kad i kako se mora. Opasno je ako zaista podaci stizu 'bez nekog pravila'. Ako su kolone na ulazu medjusobno nezavisne, onda ih ne treba drzati kao kolone u tabeli ili tabelama. Na primer, unosis podatke o lekarskim pregledima i jedan dan dobijes (BrojPregleda, PritisakGornji, PritisakDonji, BrojLeukocita, SecerUKrvi) a drugi put dobijes (BrojPregleda, Puls, RendgenPluca, StanjeKrajnika) ode je mozda dobro imati tabele:

Pregledi {BrPregleda, Datum, Lekar} PK (Brpregelda)
Parametri {Parametar} PK (Parametar)
ParametriPregleda: {BrPregleda,Parametar,Vrednost} PK (BrPregeleda, Parametar)
FK1 (BrPregleda) REF Pregledi, FK2 (Parametar) REF Parametri
Ovako bi izgledali podaci:
Code:

SELECT * FROM Parametri
;
Parametar
------------
PritisakGornji
PritisakDonji
BrojLeukocita
Puls
RendgenPluca
...

SELECT * FROM Pregeledi
;
BrPregeleda  Datum
-------------- ----------------
1                  12JUN2013
2                  16JUN2013
....

SELECT * FROM ParametriPregleda
;
BrPregelda Parametar Vrednost
------------ ----------- -----------
1               Puls          90
1               PritisakG   180
1               PritisakD   130
2               TBC          Pozitivno
2               Puls          65
2               Bilirubin     14000
3               TBC           Negativno

Uvidjas i sam verovatno prednosti a i mane ovakvog dizajna. Prednost - imas 'slobodu' da uneses kakav hoces parameter kad god ti zatreba, pod uslovom da si ga definisao u tabeli Parametri. Mane - nemas nikakvu kontrolu nad kvalitetom podataka. Kolona Vrednost priam i numericke i textualne vrednosti. Ovo se moze sipraviti sto numericke parametre cuvas u jednoj tabeli, a tekstualne u drugoj. To je sto je bolje nego ovako, ali nije dovoljno dobro. Jos uvek ne mozes da kazes nesto kao 'Leukociti moraju biti u opsegu 2000-25000'. Ov sve radi ako su podaci medjusobno nezavisni.

Kada su podaci logicki 'grupisani', bolje je mozda drzati ih u tabelama, svaki u svojoj koloni. Tada mozes da kontrolisas sta ide u koju kolonu, pod kojim uslovima, amozes I da kontrolises medjusobni odnos kolona. Recimo: Puls BETWEEN 45 AND 15, PritisakGornji > PritisakDonji, i slicne stvari.

Sve zavisi od toga sta radis.

Zidar ide na long weekend - ponedeljak je u Kanadi neradni dan, cujemo se svi u utorak.

:-)
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
92.36.196.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?01.07.2013. u 12:24 - pre 130 meseci
E sad vezano za autonumber polje kao PK. Ako imam tabelu koja mi služi samo za skladištenje source-a za neki combo box, znači u tu tabelu je nepotrebno stavljati autonumber polje. A šta je sa uštedom prostora. Zar nije bazi jeftinije skladištiti autonumber polje nego stvarni tekst kada se koristi recimo combo box. Ili je ta ušteda minorna u odnosu na komplikacije koje se mogu dobiti korištenjem autonumber-a.
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Primary key - isključen??? Kako je to moguće?02.07.2013. u 14:45 - pre 130 meseci
Citat:
A šta je sa uštedom prostora. Zar nije bazi jeftinije skladištiti autonumber polje nego stvarni tekst kada se koristi recimo combo box. Ili je ta ušteda minorna u odnosu na komplikacije koje se mogu dobiti korištenjem autonumber-a.

Pitanja su na mestu. Idemo redom.

1) Usteda prostora je najmanje vazan factor. Danas je 2013 godina, RAM se meri u gigabajtima, proctor na disku u terabajtima, proctor nije skup - prema tome, to nam je poslednja briga. Ovo ne znaci da treba cuvati opcije tipa "Popravka kucne instalacije vodovoda, od bakarnih cevi precnika 15 mm sa probom na pritisak". Ako se vec cuvaju kodovi umesto punog teksta, zasto kodovi ne bi bili tekstualni? Po cemu je kod 1 bolji nego kod GUK? Prosecan korisnik tvog sistema za pracenej diajebata zna sta je GUK, a kod 1 treba da trazi ili pokusa da zapamti. Ne znaci da ne mogu brojevi da se koriste, sve je stvar procene. Pazi, rekao sam brojevi, ne obavezno autonumber. Autonumber je samo precica, naoko oslobadja programera nekih posolva - autonumber dozvoljava programeru da bue lenj. To sto je programmer lenj, nije najgore. Najgore je sto je programmer, barem u Accesu, istovremeno i projektant baze podataka. Lenjost projektanta baze je mnogo opasnija stvar nego lenjost programera (onog ko pise kod za front end). Cinjenica da se autonumber moze automatski dodeliti i da je kvazi jedinstven, ohrabruje lenjost na nivou projektovanja baze. Tako se cesto zbog autonumbera zanemari uopste razmisljanje o nekakvom prirodnom kljucu. To nije samo teorijsko naklapanje. Autonumber dozvoljava ovakve stvari:
Code:

CREATE TABLE MOjaKodnaTabela  (Kod autonumber, Opis)
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (1, 'tra lal la') 
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (2, 'tra lal la') 
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (3, 'miki maus') 
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (4, 'tra lal la') 

Uneli smo cetiri razlicita jedinstvena koda, tri duplikata u opisu. Istina je da se ovo moze desiti i kada su kodovi tekstualni, ali se u praksi to iz nekog razloga desava mnogo redje. Zasto, ne znam, ali je mnogo redje. Verovatno zato sto dodeljivanje kodova nija automatsko, nego neko mora da sedne i da razmisli i konstruise kod, rucno ili programski. E taj deo, razmisljanje o konstruisanju koda nedostaje kada se koriste autonumbers. Sve se nekako prepusiti kompjuteru i Microsoftu, a nijedno od to dvoje nije bas pametan entitet. Kad se koristi autonumber, obicno je to JEDINO sto red u tabeli cini jedinstvenim, sve ostalo se zaboravi ili zanemari. Ako ne bi zaboravili da pronandjemo prirodni kljuc, i da razmisljamo o ostalim ogranicenjima, mozda bi se pokazalo da nam autonumber i ne treba jer nam nista ne govori o predmetu posmatranja. A ako nam nista ne govori o predmetu posmatranja, onda je to suvisan podatak.

Opet, ne kazem da ne treba koristiti autonumber i numericke kodove, ali treba biti svestan sta se time dobija a sta gubi. I ne treba nikako zanemarivati pravila procesa projektovanja. Nazalost, zanemarivanje procesa projektovanja je jako rasireno u praksi, a autonumber nam stvara lazni osecaj sigurnosti da smo eto nesto uradili po pitanju odredjivanja kljuceva.

Pravilno konstruisana kodna tabela, ako hocete da koristite brojeve, izgleda ovako:
Code:

CREATE TABLE MojaKodnaTabela2 
([Kod] int NOT NULL
, [Opis] text NOT NULL
, PRIMARY KEY ([Kod])
, UNIQUE [Opis])

Sad bar necemo moci da unesemo isti opis dva puta. Sad imamo i dva kljuca, od kojih smo jedan izabrali da bude primarni. Koji cemo kljuc izbrati da bude primarni, sasvim je svejedno. Primetite da bismo imali kljuc i da nismo uveli kolonu Kod u igru.

Problemi sa kodovima se ne zavrsavaju time sto necete da upotrebite autonumber. I ovo se desava u praksi:
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (1,'Jabuka')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (2,'Kruska')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (3,'Sljiva')

Onda se negde u neki system za prodaju unose kodovi za prodatu robu. Posle godinu dana s eneko nasali i promeni opise kodova:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 2

Jabuke koje smo godinu dana prodavali jednim potezom pera postale su lubenice. Da smo tabelu konstruisali ovako, to se ne bi desilo:

Code:

CREATE TABLE MojaKodnaTabela2 
([Kod] text(3) NOT NULL
, [Opis] text(25) NOT NULL
, PRIMARY KEY ([Kod])
, UNIQUE [Opis]
, CHECK [Kod] = LEFT([Opis],3)
)

Sad sam uradio jeres - [Kod] je postao tekst polje, pa jos i izracunato polje. Jeste izracunato polje, ali imamo i CHECK (Validation Rule na nivou tabele) koji zahteva da [Kod] bude TACNO izracunat. U tom slucaju, ovako bi zigledali kodovi:
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('JAB','Jabuka')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('KRU','Kruska')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('SLJ','Sljiva')

Pretvaranje jabuke u lubenicu ne bi proslo:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 'JAB'
Validation rule ne dozvoljava ovakvu transakciju. ne kazem da je uvek ovako jednostavno konstruisati tekstualni kod. Vazno je da vas nesto natera da o tome razmisljate, pa kakvo god resenje donesete, bice bolje nego pobeci u laznu sigurnost autonumbera ili sekvencijalnih brojeva.

Postoje bar dva slucaja koriscenja izracunatih kodova. Jedan je jedinstveni maticini broj, koji u sebi sadrzi datum rodjenja i oznaku opstine rodjenja. Drugo je VIN (vehicle identification number), serisjki broj vozila. VIN u sebi sadrzi proizvodjaca, marku vozila, model, godinu proizvodnje, mesec proizvodnje. Ako se baza pravilno konstruise, veoma je tesko podneti tudji maticni broj ili tudji VIN broj. I VIN i JMBG imaju kontrolnu cifrumoja sprecava unos nepostojecih (nepravilno konstruisanih) brojeva.








 
Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427



+19 Profil

icon Re: Primary key - isključen??? Kako je to moguće?02.07.2013. u 21:00 - pre 130 meseci
Nekada je ipak veoma korisno koristiti kvazi primarni ključ kao autonumber polje.
Primer izrade računa. Forma se uvek pravi u obliku forme i podforme i potrebno je nešto što će ih povezati .
Ako se radi u višekorisničkom okruženju vrlo je teško dobiti odmah broj računa.
Zato koristim autonumber polje koje mi služi samo za vezu. Pravi broj računa se dobija tek upisom podataka u bazu. Koristim pomoćnu tabelu u kojoj se čuva poslednji korišćen broj. U momentu snimanja ta tabela se zaključava, izračunava se broj računa, unosi se u tabelu računa i u pomoćnu tabelu, tabela računa se snima i otključava se pomoćna tabela. Naravno da podatak u tabeli ne mora da bude isključivo brojčanog tipa. Može da se koristi bilo koja rastuća ili opadajuća kontinualna funkcija koja za jedinstven ulazni podatak daje jedinstven alfanumerički niz.
 
Odgovor na temu

srdrazic

Član broj: 187994
Poruke: 509



+13 Profil

icon Re: Primary key - isključen??? Kako je to moguće?02.07.2013. u 21:34 - pre 130 meseci
A baš sam mislio da ću sa autonumberima da rešim indexiranje, nisam znao za ovakav problem, opasan problem.
Ukoliko imam tabelu : Država; Opština; Selo; Parcela; Voćnjak; Uzorak
druga tabela: vrsta_voćkarice; prečnik stabla; visina stabla
treća tabela:Vrsta voćkarice; bolest; oštećenje; tretiranje

Sada me interesuje kako postaviti ključeve ako u drugoj i trećoj tabeli za svaki zapis treba da stoji Država; Opština; Selo; Parcela; Voćnjak;Uzorak (ili neki ključ)

Ova baza je samo primer.
Teško je biti direktor a još teže ne biti!?
Prikačeni fajlovi
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Primary key - isključen??? Kako je to moguće?02.07.2013. u 22:07 - pre 130 meseci
Nisam rekao da se autonumber absolutno ne koristi. Samo treba biti pazljiv. Obratite paznju sta sve MKaras radi da bi drzao stvari pod kontrolom:
Citat:
Zato koristim autonumber polje koje mi služi samo za vezu. Pravi broj računa se dobija tek upisom podataka u bazu. Koristim pomoćnu tabelu u kojoj se čuva poslednji korišćen broj. U momentu snimanja ta tabela se zaključava, izračunava se broj računa, unosi se u tabelu računa i u pomoćnu tabelu, tabela računa se snima i otključava se pomoćna tabela. Naravno da podatak u tabeli ne mora da bude isključivo brojčanog tipa. Može da se koristi bilo koja rastuća ili opadajuća kontinualna funkcija koja za jedinstven ulazni podatak daje jedinstven alfanumerički niz.
Autonumber postoji, ali postoji i sve ostalo. Autonumber se koristi za vezu, da se brze napise kveri, a sve ostalo postoji da garantuje integritete podataka. To nije jednostavno, ali Mkaras sebi moze da dozvoli Autonumber, jer covek zna sta radi. Opasno je kad je autonumber 'resenje za sve'. Nije. I Mkaras ga i ne koristi za ono zasta bi ga ostali koristili.

Citat:
Sada me interesuje kako postaviti ključeve ako u drugoj i trećoj tabeli za svaki zapis treba da stoji Država; Opština; Selo; Parcela; Voćnjak;Uzorak (ili neki ključ)
Bas tako. Kljuc se iz roditalj tabele prenosi u dete tabelu. A kljuc moze da ima I vise kolona, zasto da ne. Ako mislis da ce ti uvodjenje numerickog vetsackog kljuca pomoci, gresis.

Primer koji navodis nije bas najsrecniji, ali posluzice. Recimo da u vocnjaku uzimas uzorke.
Onda je Vocnjak2: {Država; Opština; Selo; Parcela; Voćnjak, PRIMARY KEY (Država; Opština; Selo; Parcela; Voćnjak)}
ili uvedes jos jenu numericku kolonu, da imas laksu vezu sa drugim tabelama:
Vocnjak1: {Država; Opština; Selo; Parcela; Voćnjak, VocnjakID numeric, PRIMARY KEY VocnjakID , UNIQUE (Država; Opština; Selo; Parcela; Voćnjak)}

Posto si uzorak useo u nekom vocnjaku, mozes ovo da imas u tabeli Uzorci:

Uzorak1: (BrUzorka numeric, VocnjakID numeric PRIMARY KEY BrUzorka FOREIGN KEY (VocnjakID) REF Vocnjak1 (VocnjakID)}
ili
Uzorak2: {Država; Opština; Selo; Parcela; Voćnjak, BrUzorka PRIMARY KEY (BrUzorka )
FOREIGN KEY (Država; Opština; Selo; Parcela; Voćnjak, BrUzorka)
REFRENCES Vocnjak2 (Država; Opština; Selo; Parcela; Voćnjak, BrUzorka) }
mnogo vise pisanja, ali smao jednom I bas te briga. Tze za unos podataka? Nije istina, jer se vezna polja u subformama popunjavaju automatski. Ja ih I ne prikazujem na subformama, ostaju sakrivena i korisnik ih ne vidi..

Elem, Uzorka1 ima dve kolone, obe numericke i nikad ne znas sta one znace, jer tabela izgleda ovako:
Code:

SELECT * FROM Uzorak1
BrUzorka VocnjakID
1         1
2         1
3         1
4         2
5         2

Ako BrUzorka = 5 vezes za VocnjakID = 1, ko ce da primeti gresku? Niko nikada.
A moze tabela da izgled i ovako:
Code:

SELECT * FROM Uzorak2
Država; Opština; Selo;  Parcela;  Voćnjak BrUzorka
SR         KG          GRB       120/06    SEV     45

SR = Srbija, KG = Kragujevac, GR = Grbice, PArcela je 120/06 i vocnjak jse zove 'Severni' i znamo da za Grbice dozvoljavamo opseg uzoraka od 30-50, onda ono sto cuvamo u tabeli Uzorak2. Ovakva tabela, Uzorak2, mnogo vise govori o nasim podacima i dozvoljava da se uvede nekkava logicka kontrola (citaj INTEGRITET PODATAKA). Napises CONSTRAINT koji kaze 'Ako Opstina = 'KG' I Selo = 'Grb' => BrUzorka BETWEEN 30 AND 50. Access ima operator IMP koji radi isto sto I => u mtematici (IMP od implikacija, pa zasto to ne iskoristiti?) Istina, moze da se ovako razmislja i kad imas numericke kodove, ali se obicno ne razmislja. Razmislja se o indeksima i autonumberima. Autonumberi nisu tu zbog indeksiranja, niti mi ovaj posao radimo zbog indeksiranja. Radimo ga da bi imali ciste i tacne podatke, koje je tesko pokvariti, na unosu ili kasnije. Ako ne umes da vidis sta redove u tabeli cini jedinstvenim, ili ne postoji takva kombinacija, onda nesto ne valja u dizajnu baze, i to se ne moze resiti uvodjenjem vestackih kljuceva koji ce jednim potezom doneti jedinstvenost.

 
Odgovor na temu

srdrazic

Član broj: 187994
Poruke: 509



+13 Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 06:52 - pre 130 meseci
Nije problem sa održavanjem baze kada ja vodim računa o njoj, ali kada date ili poklonite nekom bazu da sebi olakša život a ne razume se baš najbolje, onda te zovne i kaže a šta mi se ovo desilo, ja nisam ništa dirao? Zbog toga me plaši polje autonumber.

Što se tiče mog primera, {Država; Opština; Selo; Parcela; Voćnjak,} treba da je jedinstven dok se Uzorci ponavljaju za svaki voćnjak od 01,02.....n.
Ne bi bilo srećno rešenje da dodam još jednu kolonu pa da ručno unosim nekakav ID.

{Država; Opština; Selo; Parcela; Voćnjak,} ova polja će se numerički obeležavati (šifrirati) a ne tekstualno.

Ranije sam pokušao da na formi napravim još jedno polje ID= [Grad]&" "&[Opština]&" ........ "&[Voćnjak] pa da ga automatski ubaci u subformu, ali nisam našao načina da ga korisnik nekim event-om realizuje jer uvek se desi da ga preskoči i taj code se ne izvrši.

Možda je malo baza komplikovana jer za svaki voćnjak uzorci se obeležavaju od 01,02....n, u drugom voćnjaku se to ponavlja od 01,02....n.
U novom selu brojevi parcela i voćnjaka se mogu ponavljati.

Recimo:

Selo Parcela Voćnjak Uzorak
22 122 01 01
22 122 01 02
22 122 02 03
22 122 01 04
22 122 02 05
22 445 01 01
22 445 01 02
22 445 03 03
22 445 02 04
25 122 01 01
25 122 01 02
25 122 01 03
........................................................

[Ovu poruku je menjao srdrazic dana 03.07.2013. u 08:33 GMT+1]
Teško je biti direktor a još teže ne biti!?
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
109.163.158.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 10:07 - pre 130 meseci
Da rezimiram da vidim jesam li shvatio (a i za one koji tek pocinju sa access-om):

1. Svaka tabela treba i mora imati PK

2. Tabele koje ce biti source za npr. combo box sa jednom kolonom, nepotrebno je dodavati ID polje jer su svi unosi u toj tabeli jedinstveni pa tu kolonu mozemo staviti kao PK a radi veze, ali ukljuciti referencijalni integritet ako zelimo da ukoliko npr. pogresimo kod nekog unosa, ispravkom bi se tad izvrsio update u svim poljima u vezanoj tabeli. (mada nam nekad to mozda i ne treba) kao sto je napisao Zidar:

Citat:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 2


Koristenjem autonumber polja i bez referencijalnog integriteta, ako izmijenimo neki unos, s obzirom da je veza autonumber polje (korisnik ne vidi (ali i moze da vidi) number nego drugu kolonu) automatski bi mu se "izmijenili" svi podaci za to polje.

3. Za radne tabele (one koje se kontinuirano pune) postaviti PK na ono polje koje je jedinstveno za svaki unos. Ako takvo ne postoji probati za PK postaviti kombinaciju polja koja se unose u tu tabelu. Ako i to ne moze, probati generisati neko polje na neki nacin (malo ukljuciti kreativnost), pa ako i to ne moze onda definisati autonumber polje kao PK.

Je li to to.
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
109.163.158.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 10:42 - pre 130 meseci
Citat:
srdrazic:
A baš sam mislio da ću sa autonumberima da rešim indexiranje, nisam znao za ovakav problem, opasan problem.
Ukoliko imam tabelu : Država; Opština; Selo; Parcela; Voćnjak; Uzorak
druga tabela: vrsta_voćkarice; prečnik stabla; visina stabla
treća tabela:Vrsta voćkarice; bolest; oštećenje; tretiranje

Sada me interesuje kako postaviti ključeve ako u drugoj i trećoj tabeli za svaki zapis treba da stoji Država; Opština; Selo; Parcela; Voćnjak;Uzorak (ili neki ključ)

Ova baza je samo primer.


Samo jedno pitanje ako se radi o nekoj konkretnoj bazi:

koliko tabela ona ima, jer ova tabela meni izgleda nelogicno: Drzava; Opstina; Selo; Parcela; Vocnjak; Uzorak


 
Odgovor na temu

srdrazic

Član broj: 187994
Poruke: 509



+13 Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 11:18 - pre 130 meseci
To je samo banalan primer na konkretan problem, samo da prikažem kakva putanja do uzorka može biti.
Može biti: Opština, Katastarska opština, parcela, uzorak ...

Teško je biti direktor a još teže ne biti!?
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
109.163.152.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 12:09 - pre 130 meseci
Ovdje dolazi do izrazaja pravilno oznacavanje odredjenih polja.

Ako u ovom banalnom primjeru na pregledan nacin oznacimo npr vocnjake. Samim jednim odabirom vocnjaka vec smo odabrali i Drzavu i Opstinu i Selo i Parcelu, ali uz preduslov da je dobro dizajnirana baza i da su u bazu vec uneseni sifrarnici za Drzavu, Opštine u Državi, Sela u Opštini, Parcele u Selu i Vocnjaci u parceli.

Npr. ako se neki konkretni vocnjak oznaci sa: KG-GRB-120/06-SEV i to bude njegov jedinstveni ID i kad hocemo da unesemo odredjeni uzorak uzet na odredjeni datum (mozda bi datum bio dobra polazna tacka za odredjivanje ID za uzorak) za taj vocnjak, izabirom tog vocnjaka automatski se zna kojoj drzavi, opstini, selu i parceli taj vocnjak pripada.

To je bar moje misljenje.
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
109.163.152.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 12:22 - pre 130 meseci
Sad bi ja postavio drugo pitanje:

Vecina nas koji smo tek zagazili u access smo u vecini baza i tabela postavili autonumber kao PK. Kako popraviti stanje, ako je moguce.

Npr. ja licno bih mogao u nekim tabelama postaviti PK na neko drugo polje, ali da li je to komplikovana procedura i isplati li se kad se vec u bazi nalazi hiljade record-a.

Sad razmisljam i ne znam kako bih za sifrarnike na koje sam vezan sa number poljem sad prebacio pa da se vezem sa textualnim poljem, kad je u radnoj tabele sve number.

Jedino mozda da napravim make table query, ali to zahtijeva potpuno cijepanje, rusenje, demoliranje i krpljenje radnih tabela.
 
Odgovor na temu

srdrazic

Član broj: 187994
Poruke: 509



+13 Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 12:31 - pre 130 meseci
Previše je to karaktera za unos jednog voćnjaka ručno ako uzmemo u obzir da ih ima na hiljade u jednoj državi.
To sam pokušao automatski generisati na event lostfokus polja [uzorak] generiše se ID spajanjem svih polja u jedno:
npr. država=25; opština= 22; selo=15; Parcela=1208; voćnjak = 11; uzorak=01
ID=25221512081101 , to je na formi

a subforma ima ID ; vrsta voćkarice; prečnik;visina
druga subforma ID; vrsta voćkarice; bolest; oštećenje; tretiranje

Na brzinu sam napravio primer pa ima nelogičnosti ali ovo je otprilike suština.
Teško je biti direktor a još teže ne biti!?
 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
109.163.152.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 12:43 - pre 130 meseci
Koliko vidim kada hoce da se unese odredjeni uzorak za odredjeni vocnjak, nekako mi puno koraka da se dodje do odredjenog vocnjaka.

Ili ima neka shortcut procedura. :-)

 
Odgovor na temu

srdrazic

Član broj: 187994
Poruke: 509



+13 Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 13:04 - pre 130 meseci
Nema, to je jedina putanja do jedinstvenog voćnjaka ;-)
Teško je biti direktor a još teže ne biti!?
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 16:19 - pre 130 meseci
Citat:
Koliko vidim kada hoce da se unese odredjeni uzorak za odredjeni vocnjak, nekako mi puno koraka da se dodje do odredjenog vocnjaka.

Ili ima neka shortcut procedura.


Moze ovako:
Citat:
To sam pokušao automatski generisati na event lostfokus polja [uzorak] generiše se ID spajanjem svih polja u jedno:
npr. država=25; opština= 22; selo=15; Parcela=1208; voćnjak = 11; uzorak=01
ID=25221512081101 , to je na formi
Kako ce se 'komplikovani' podatak uneti, sekundarno je pitanje. Primerno je da se postavi ogranicenje na tabeli koje nece dozvoliti neispravan podatak. U ovom slucaju, neka imamo kod koji definise ogranicenje bi se ovako napisalo:

LEFT(ID,2) = [Drzava]
AND MID(ID,3,2) = [Opstina]
AND MID(ID,5,2) = [Selo]
AND MID(ID,7,2)= [Parcela]
AND MID(ID,9,2) = [Vocnjak]
AND Right(ID,2) = [Uzorak]

Ako gornij izraz ubacis u validation rule za tabelu, onda ces morati da konstruises ID po tom pravilu, inace ce tabela odbaciti unos.

Kako da garantujes da ce se ID konstruisati pravilo kroz programski kod? Nemoj da koristis GetFocus polja Uzorak. Koristi dogadjaj BeforeUpdate za formu. Na BeforeUpdate za formu stavis ovo:
me!ID = [Drzava] & [Opstina] & [Selo] & [Parcela] & [Vocnjak] & [Uzorak]
Podrazumeva se da je ID nevidljivo, ili barem Locked=TRUE. Ako unapred pretpostavis koliko ce se uzoraka uzimati po vocnjaku, moze ovo d auradi unapred, pa pripremis labele sa bar-kodovima i das ih uzimacima uzoraka, da nalepe na kontejner sa uzorkom, pa kada dostave uzorke samo skeniras barcode itd...


Citat:

Vecina nas koji smo tek zagazili u access smo u vecini baza i tabela postavili autonumber kao PK. Kako popraviti stanje, ako je moguce.

Npr. ja licno bih mogao u nekim tabelama postaviti PK na neko drugo polje, ali da li je to komplikovana procedura i isplati li se kad se vec u bazi nalazi hiljade record-a.

Sad razmisljam i ne znam kako bih za sifrarnike na koje sam vezan sa number poljem sad prebacio pa da se vezem sa textualnim poljem, kad je u radnoj tabele sve number

Ako je evc psotavljeno sa autonumber, ostavi ga, sad je najverovatnije kasno. Rekosmo na pocetku da se autonumber obilato koristi I uglavnom radi bez problema. Problem koji je opisan ne javlja se cesto, nit se one izmene koje pominjem bas tako desavajusvaki dan. kako svima, tako I tebi Za ubuduce, razmisljate o ogranicenjima (uniqueness, medjusobni odnos polja, foreign keys), I nemojte odmah autonumber da potezete. Ako bas nista drugo ne moze, onda zasto ne I autonumber. Naglasak je na 'ako bas nista drugo ne moze' , jer obicno - moze, samo treba malo razmisliti I ne zuriti da se posto-poto pocne pisati program. Kad jednom napisete program, kasno je za ispravke ovog tipa.


 
Odgovor na temu

fahre72
Zenica

Član broj: 303817
Poruke: 32
31.176.143.*



Profil

icon Re: Primary key - isključen??? Kako je to moguće?03.07.2013. u 17:40 - pre 130 meseci
Citat:
fahre72:
Da rezimiram da vidim jesam li shvatio (a i za one koji tek pocinju sa access-om):

1. Svaka tabela treba i mora imati PK

2. Tabele koje ce biti source za npr. combo box sa jednom kolonom, nepotrebno je dodavati ID polje jer su svi unosi u toj tabeli jedinstveni pa tu kolonu mozemo staviti kao PK a radi veze, ali ukljuciti referencijalni integritet ako zelimo da ukoliko npr. pogresimo kod nekog unosa, ispravkom bi se tad izvrsio update u svim poljima u vezanoj tabeli. (mada nam nekad to mozda i ne treba) kao sto je napisao Zidar:

Citat:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 2


Koristenjem autonumber polja i bez referencijalnog integriteta, ako izmijenimo neki unos, s obzirom da je veza autonumber polje (korisnik ne vidi (ali i moze da vidi) number nego drugu kolonu) automatski bi mu se "izmijenili" svi podaci za to polje.

3. Za radne tabele (one koje se kontinuirano pune) postaviti PK na ono polje koje je jedinstveno za svaki unos. Ako takvo ne postoji probati za PK postaviti kombinaciju polja koja se unose u tu tabelu. Ako i to ne moze, probati generisati neko polje na neki nacin (malo ukljuciti kreativnost), pa ako i to ne moze onda definisati autonumber polje kao PK.

Je li to to.






Znaci za ovo moje od prije sam bio u pravu
 
Odgovor na temu

[es] :: Access :: Primary key - isključen??? Kako je to moguće?

Strane: 1 2

[ Pregleda: 4447 | Odgovora: 22 ] > FB > Twit

Postavi temu Odgovori

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