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

Relacione baze .. spajanje preko id ili multiple column

[es] :: Baze podataka :: Relacione baze .. spajanje preko id ili multiple column

[ Pregleda: 3174 | Odgovora: 10 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
37.203.81.*



+1 Profil

icon Relacione baze .. spajanje preko id ili multiple column04.10.2015. u 13:09 - pre 104 meseci
Pozdrav,
imam dvije tablice u bazi,
zaglevlje (firma,vrsta_dokumenta,broj_dokumenta,....)
stavke ((firma,vrsta_dokumenta,broj_dokumenta,broj_stavke....))



da li ove dvije tablice spojiti foregin key
Code:
FOREIGN KEY (`firma`, `vrsta_dokumenta`, `broj_dokumenta`) REFERENCES `otpremnica_stavke` (`firma`, `vrsta_dokumenta`, `broj_dokumenta`) 


ili dodati jos jednu kolonu id int auto increment i onda

Code:
FOREIGN KEY (`id`) REFERENCES `stavke` (`id`) 


Razmisljam da ce ovaj drugi nacin mozda u pogledu performansi biti bolji..

Molim Vas za vasa misljenja.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column04.10.2015. u 14:11 - pre 104 meseci
Citat:
mojeKorIme: Pozdrav,
imam dvije tablice u bazi,
zaglevlje (firma,vrsta_dokumenta,broj_dokumenta,....)
stavke ((firma,vrsta_dokumenta,broj_dokumenta,broj_stavke....))


Prvo u obe tabele uvedes po jedan ID, kao primary key. Ne znam ni jedan storage engine koji radi bez primarnog kljuca, a ne zelis da ti storage engine sam skriveno pravi kompozitni primarni kljuc, to ce ti tek upucati performanse.

Onda ili :

a) Uvedes u "Stavke" taj ID_Zaglavlje kao foreign key i NE KOPIRAS iste podatke u obe tabele.
b) Napravis tabelu stavke, posto u njoj vec imas sve i ubijes tabelu Zaglavlje. :)

Kopiranje podataka u obe tabele ima smisla, kao denormalizacija ako su ti performanse JAKO bitne, ali ne kapiram da ce ti upit po primarnom kljucu nad tom tabelom ikad biti spor, ako je sustina da u njoj drzis interna dokumenta nekog pojedinacnog preduzeca..... Znam dosta slucajeva kad ima smisla raditi denormalizaciju, mogu da zamislim i document management sistem kome to treba, ali ne ako on glumi delovodnik ili tako nesto.... Morao bi da imas bas milione dokumenata da bi se to osetilo. Pro tom takva denormalizacija daje ubrzanje u citanju, ali i usporenje u pisanju, plus ako ti ako ti ikad zatreba sva data iz Zaglavlja, ode sve nazad.


Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
31.176.228.*



+1 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column04.10.2015. u 16:42 - pre 104 meseci
nkrgovic hvala na odgovoru.. ne bih "ukidao" tablicu Zaglavlje jer ona naravno sadrzi jos dodatnih podataka kao sto su datum, napomena,...
ideja je da ce u istoj tablici biti vise firmi,znaci u zavisnosti ko se loguje radice na svojoj "firmi" .. znaci zakljucak je da umjesto kompozitnih primarnih kljuceva dodam
neki id i to je to bez dodatnih zapetljancija
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1343
*.dynamic.sbb.rs.



+311 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column04.10.2015. u 16:59 - pre 104 meseci
Stavi ID u obe tabele kao što je nkrgović rekao, biće ti život lakši.
Isto tako, ne bi bilo loše da staviš unique constraint na kolone
firma,vrsta_dokumenta,broj_dokumenta u zaglavlju
i isto unique na id_zaglavlja, broj_stavke u tabeli stavke.

 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.dsl.bell.ca.



+79 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column06.10.2015. u 03:51 - pre 104 meseci
Pitanje je naslovljeno sa "Relacione Baze,, spajanje preko Id ili multiple column", pa ga treba resavati- relaciono. Dodavanje Id nema nikakve veze sa relacionom teorijom, ima i razloga zasto. Sad je kasno kod mene, skoro ponoc, za jedno 10 sati od ovog momenta razjasnicu sta sam mislio. Osim ako postavljac teme ne kaze "Hvala ne treba"

 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column06.10.2015. u 22:14 - pre 104 meseci
Za sada samo kod, koji ce nam trebati za diskusiju (sutra):
[code]
http://www.elitesecurity.org/t...e-preko-id-ili-multiple-column


-- Opcoija sa kompozitnim kljucem
IF OBject_ID('MKI_Stavke') IS NOT NULL DROP TABLE MKI_Stavke
;
IF OBject_ID('MKI_Zaglavlje') IS NOT NULL DROP TABLE MKI_Zaglavlje
;
CREATE TABLE MKI_Zaglavlje
(
Firma nvarchar(50) NOT NULL
, Vrsta_Dokumenta nvarchar(50) NOT NULL
, Broj_Dokumenta nvarchar(20) NOT NULL
PRIMARY KEY (Firma,Vrsta_Dokumenta,Broj_Dokumenta)
)
GO

CREATE TABLE MKI_Stavke
(
Firma nvarchar(50) NOT NULL
, Vrsta_Dokumenta nvarchar(50) NOT NULL
, Broj_Dokumenta nvarchar(20) NOT NULL
, Broj_Stavke int NOT NULL
, NazivArtikla nvarchar(50) NOT NULL
, Kolicina decimal (12,4) NOT NULL
, PRIMARY KEY (Firma,Vrsta_Dokumenta,Broj_Dokumenta, Broj_Stavke)
)
GO

ALTER TABLE MKI_Stavke
ADD CONSTRAINT [FK1 Stavke: (Firma,Vrsta_Dokumenta,Broj_Dokumenta) mora da ima odgovarajuci red u tabeli Firme]
FOREIGN KEY (Firma,Vrsta_Dokumenta,Broj_Dokumenta)
REFERENCES MKI_Zaglavlje (Firma,Vrsta_Dokumenta,Broj_Dokumenta)
GO


-- Opcija sa Id:
IF OBject_ID('MKI_Stavke') IS NOT NULL DROP TABLE MKI_Stavke
;
IF OBject_ID('MKI_Zaglavlje') IS NOT NULL DROP TABLE MKI_Zaglavlje
;

CREATE TABLE MKI_Zaglavlje
(
Id int identity PRIMARY KEY
, Firma nvarchar(50) NOT NULL
, Vrsta_Dokumenta nvarchar(50) NOT NULL
, Broj_Dokumenta nvarchar(20) NOT NULL
)
GO

CREATE TABLE MKI_Stavke
(
Id int NOT NULL
, Broj_Stavke int NOT NULL
, NazivArtikla nvarchar(50) NOT NULL
, Kolicina decimal (12,4) NOT NULL
, PRIMARY KEY (Id, Broj_Stavke)
)
GO
ALTER TABLE MKI_Stavke
ADD CONSTRAINT [FK1 Stavke: (Id) mora da ima odgovarajuci red u tabeli Firme]
FOREIGN KEY (Id)
REFERENCES MKI_Zaglavlje (Id)
GO
[\code]
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column07.10.2015. u 07:02 - pre 104 meseci
Cekam pojasnjenje, ali da samo pokazem sta sam ja mislio:

Meni je problem bilo ovo:

Citat:
Zidar: PRIMARY KEY (Firma,Vrsta_Dokumenta,Broj_Dokumenta, Broj_Stavke)


Ali mi resenje nije bilo ovo:

Citat:
PRIMARY KEY (Id, Broj_Stavke)


Vec da se napravi isto ID u toj tabeli, kao u Zaglavlje:
Citat:

Id int identity PRIMARY KEY


A da se doda dodatni vezni integer, tipa ID_Zaglavlja koji bi bio foreign key. Cilj je da svaka tabela ima jedan INT Primary Key. Razlozi su nacin kako sve relacione baze, tj. njihovi storage engine-i rade. :)

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column14.10.2015. u 19:19 - pre 104 meseci
Izvinjavam se za pauzu,mora covek nekad i na poslu nesto da radi... A onda mi je odgovor otisao 'u vazduh'. sva sreca, sacuvao sam kopiju u text fajlu. Da probamo sada:

Izvinjavam se za nejavljanje, bilo je mnogo obaveza, pa eto.

Problem sa uvodjenjem vestackog Id, autoinkrement ili ne jeste sto se cesto zaboravi na prirodni, realni kljuc, koji naravno moze biti sastavljen od vise od jedne kolone. Moja verzija sa upotrebom ID u tabeli Zaglavlje pati od upravo takve greske. Ovo sam bio predlozio:
Code:

IF OBject_ID('MKI_Stavke') IS NOT NULL DROP TABLE MKI_Stavke
;
IF OBject_ID('MKI_Zaglavlje') IS NOT NULL DROP TABLE MKI_Zaglavlje
;

CREATE TABLE MKI_Zaglavlje 
(
Id int identity PRIMARY KEY
, Firma nvarchar(50) NOT NULL
, Vrsta_Dokumenta nvarchar(50) NOT NULL
, Broj_Dokumenta nvarchar(20) NOT NULL
)
GO

Evo sta se moze disti:
Code:

INSERT INTO MKI_Zaglavlje (Firma, Vrsta_Dokumenta, Broj_Dokumenta)
VALUES ('PKB','Faktura','2015-152')
     , ('PKB','Faktura','2015-152')
     , ('PKB','Faktura','2015-152')
     , ('TTU','Otpremnica','2015-007')
;
-- (4 row(s) affected)
SELECT * FROM MKI_Zaglavlje;

         Id Firma    Vrsta_Dokumenta   Broj_Dokumenta
----------- -------- ----------------- --------------
          1 PKB      Faktura           2015-152
          2 PKB      Faktura           2015-152
          3 PKB      Faktura           2015-152
          4 TTU      Otpremnica        2015-007

(4 row(s) affected)

Uneo sam dakle 3 puta iste podatke - 'PKB','Faktura','2015-152', bez ikakvih problema. Jedino se razlikuju vrednosti za ID. To nije dobro i to ne mozemo ostaviti front-end programeru da resava. Programi i programeri dolaze i odlaze, a baza ostaje, godinama i nikad se ne zna ko ce i kada da zaboravi da na front endu postavi neophodne uslove integriteta (jedinstvenost je uslov integriteta podataka). Da bi se ti problemi izbegli, uslovi integriteta se deklarisu na nivou tabele u bazi podataka. Ako pokusam da uspostavim uslov UNIQUE (Firma, Vrsta_Dokumenta, Broj_Dokumenta) nece mi uspeti, jer tabela vec sadrzi duplikate (triplikate :-). Zato moram da obrisem sta imam u tabeli i da probam ponovo:
Code:

ALTER TABLE MKI_Zaglavlje ADD CONSTRAINT
[U tabeli Zaglavje kombinacija (Firma, Vrsta_Dokumenta, Broj_Dokumenta) mora biti jedinstvena!]
UNIQUE (Firma, Vrsta_Dokumenta, Broj_Dokumenta)

Msg 1505, Level 16, State 1, Line 1
The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name 'dbo.MKI_Zaglavlje' and the index name 'U tabeli Zaglavje kombinacija (Firma, Vrsta_Dokumenta, Broj_Dokumenta) mora biti jedinstvena!'. The duplicate key value is (PKB, Faktura, 2015-152).
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
The statement has been terminated.


Zato oram prvo da uradim ovo
Code:
 DELETE FROM MKI_Zaglavlje
-- (4 row(s) affected)

ALTER TABLE MKI_Zaglavlje ADD CONSTRAINT
[U tabeli Zaglavje kombinacija (Firma, Vrsta_Dokumenta, Broj_Dokumenta) mora biti jedinstvena!]
UNIQUE (Firma, Vrsta_Dokumenta, Broj_Dokumenta)
GO
-- Command(s) completed successfully.

Da probamo ponovo da unesemo duplikate:
Code:

INSERT INTO MKI_Zaglavlje (Firma, Vrsta_Dokumenta, Broj_Dokumenta)
VALUES ('PKB','Faktura','2015-152')
     , ('PKB','Faktura','2015-152')
     , ('PKB','Faktura','2015-152')
     , ('TTU','Otpremnica','2015-007')
;
Msg 2627, Level 14, State 1, Line 1
Violation of UNIQUE KEY constraint 'U tabeli Zaglavje kombinacija (Firma, Vrsta_Dokumenta, Broj_Dokumenta) mora biti jedinstvena!'. Cannot insert duplicate key in object 'dbo.MKI_Zaglavlje'. The duplicate key value is (PKB, Faktura, 2015-152).
The statement has been terminated.
Ovaj put unos je odbacen, kako i treba. Da probamo korektan slucaj:
Code:

INSERT INTO MKI_Zaglavlje (Firma, Vrsta_Dokumenta, Broj_Dokumenta)
VALUES ('PKB','Faktura','2015-152')
     , ('TTU','Otpremnica','2015-007')
;
-- (2 row(s) affected)

         Id Firma    Vrsta_Dokumenta   Broj_Dokumenta
----------- -------- ----------------- --------------
          7 PKB      Faktura           2015-152
          8 TTU      Otpremnica        2015-007

(2 row(s) affected)

Unos je uspeo ovaj put. Ali, ima jedna ruzna stvar - Id je poceo od 7, a ne od 1, iako smo obrisali sve iz tabele pre unosa. To je drugi problem sa autoinkrement Id vrednostima - nemate nikakvu kontrolu nad njima. Kako ce programer na front endu da zna koji je Id sistem dodelio novom redu? Naravno da postoje funkcije da se to uradi, unutar DBMS, ali nazalost, ne zna ih svako. U MS SQL, da li upotrebiti @@Identity, Scope_Identity(), Ident_Current()? Ili nesto trece? A to nam treba da bi dodali stavke u tabelu MKE_Stavke. Ako radite u MS Access, ovo sve nije problem jer Access zna da prenese identity iz roditelj tabele u dete tabelu, bez ikakvog koda. Ali, access je zastareo, sada je u mdi .NET, jeste da zahteva oko 10 puta vise vremena da se isti posao odradi, ali je bar moderno :-)

Ali hajde, neka nam Id u MKE_Zaglavlje, uz uslov da smo postavili UNIQUE ogranicenje na tri kolone koje cine prirodni kljuc. Da predjemo na dete tabelu, MKE_Stavke. ja sam predlozio:
Code:

CREATE TABLE MKI_Stavke
(
Id int NOT NULL
, Broj_Stavke int NOT NULL
, NazivArtikla nvarchar(50) NOT NULL
, Kolicina decimal (12,4) NOT NULL
, PRIMARY KEY (Id, Broj_Stavke)
)
GO
ALTER TABLE MKI_Stavke 
ADD CONSTRAINT [FK1 Stavke: (Id) mora da ima odgovarajuci red u tabeli Firme]
FOREIGN KEY (Id)
REFERENCES MKI_Zaglavlje (Id)
GO 
Da probamo nekoliko stavki, sve korektne, bez duplikata:
Code:

INSERT INTO MKI_Stavke (Id, Broj_Stavke, NazivArtikla, Kolicina)
VALUES (8,1,'Cokolada',2)
        , (8,2,'Mleko',1)
        , (8,3,'Hleb',1)
GO
-- (3 row(s) affected)

INSERT INTO MKI_Stavke (Id, Broj_Stavke, NazivArtikla, Kolicina)
VALUES (7,1,'Cokolada',2)
        , (7,2,'Mleko',1)
        , (7,3,'Cokolada',1)
;
-- (3 row(s) affected)

SELECT * 
FROm MKI_Stavke
ORDER BY Id, Broj_Stavke
;

         Id Broj_Stavke NazivArtikla  Kolicina
----------- ----------- ------------ ---------
          7           1 Cokolada         2.0000
          7           2 Mleko            1.0000
          7           3 Cokolada         1.0000
          8           1 Cokolada         2.0000
          8           2 Mleko            1.0000
          8           3 Hleb             1.0000

(6 row(s) affected)
Da probamo duplikat, cisto zbog dokumentacije:
Code:
INSERT INTO MKI_Stavke (Id, Broj_Stavke, NazivArtikla, Kolicina)
VALUES (8,1,'Kisela voda',2)
        , (8,2,'Jogurt',1)

Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK__MKI_Stav__7F385C6B8161C3FF'. Cannot insert duplicate key in object 'dbo.MKI_Stavke'. The duplicate key value is (8, 1).
The statement has been terminated.


Vratimo se na unose koji su prosli. Pogledajte otpremnicu za zaglavlje Id = 7. Cokolada se pojavljuje dva puta, pod brojem 1 i pod brojem 3. da li je to u redu? Zavisi od zadatka. Ako se radimo kasu za samouslugu, onda se moze dozvoliti, jer se cokolada moze naci na pocetku, a nesto kasnije i druga, ista takva cokolada. To je jedini slucaj gde ima smisla dozvoliti da se isti artikl pojavi vise nego jednom, na istom dokumentu - racun koji dobijete na kasi. U nasem slucaju, dokument koji modelujemo je otpremnica, pa sumnjam da bi se dozvolilo da isti artikl bude pomenut vise puta. U svakom slucaju, ako se isti artikl ne sme pojaviti dva puta na istom dokumentu, onda nam treba jos jedna UNIQUE constraint, UNIQUE (ID, NazivArtikla). I naravno da nam treba i FK koji referencira nekakvu tabelu Artikli, po NazivArtikla (ili nekakav kod artikla, bar code ili slicno, ne utice na princip).

Ako bismo uradili ovo, po predlogu Nikolinom:
Code:

CREATE TABLE MKI_Stavke
(
IdZaglavlja int NOT NULL FOREIGN KEY REFERENCES MKI_Zaglavlje (ID)
, IdStavke int NOT NULL PRIMARY KEY
, NazivArtikla nvarchar(50) NOT NULL
, Kolicina decimal (12,4) NOT NULL
)
GO
onda bi imali potnecijalni problem sa ponavljanjem NazivArtikla za isto IdZaglavlja i kada je to zabranjeno, a zabranjeno je cesce nego sto je dozvoljeno. Da bi to sprecili, treba nam ponovo UNIQUE (IdZaglavlja,NAzivArtikla), kao i u mom resenju. Posto je to unique, zasto bismo uvodili novi IdStavke, autoincement ili ne? JOIN ce biti po Zaglavlje.ID = Stavke.IdZaglavlja, sta jos ima u unikue kombinaciji u Stavkama. Ako pak prihvatimo da (SaglavljeID,NazivArtikla) bude PK, mozemo da ga napravimo da bude CLUSTER INDEX te da nemamo da odrzavamo zasebni ineks, ma kako bio mali i brz.

Da rezimiramo, dodavanje vestackog int kljuca, autoinkrement ili ne, ne donosi nikakve prednosti osim sto se JOIN pise lakse. Posto prirodni kljuc moramo definisati, ne stedimo na prostoru, jer umesto jednog indexa za prirodni kljuc, sada imamo i dodatni, za vestacki kljuc. U roditelj tabelama, makar i imali trokolonski PK, cesto mu je struktura takva da se moze realizovati kroz CLUSTER INDEX cime sama tabela postaje index file, na fizickom nivou, a od toga nista brze nema. Ako prenesemo trokolonski kluc u tabelu dete, (Stavke), onda ima jos vise smisla da kompozitni kljuc (koji ce sad imati 4 kolone) bude baziran na CLUSTER INDEX, pa nemate problema sa brzinom, ako je brzina u pitanju. Argument tipe 'stedi se na disk prostoru' danas naprosto ne vazi, prostor na disku je skoro besplatan.

Ako su kveriji ili aplikacije spore, moze biti mnooogo razloga, a 'velicin' i 'slozenost' kljuca igraju najmanju ulogu u svemu tome. Mozete da imate sve kljuceve jednokolonske, integer, a da vam front end zapinje i skripi zato sto pri unosu nesvesno lokirate tabele, pa transakcije cekaju na red da se izvrse. A pogotovo kad na front endu otvorite transakciju, pa zaboravite da COMMIT na primer. Ili osim PK/FK nemate druge indekse na tabelama, a imate protrebu da vezujete tabele po drugim kolonama. Ili upotrebite na front endu omiljenu taktiku za sprecavanje duplikata - svaki unos se trazi u bazi da li postoji, pa ako ne postoji, ide transakcija, a ako postoji, onda se naravno zaustavlje. Problem je u tome sto je procenat potencijalnih duplikata veoma mali, recimo 1%, a vi 100% puta trosite vreme na search koji ne vraca nista. takodje, nacin na koji je front end povezan sa bazom igra oromnu ulogu, kako povlacite podatke, mnogo ili malol, na koji nacin filtrirate ono sto ce se prikazati i slicno.

Ako postujete pravila projektovanja relacionih baza ( a to nije samo normalizacija ), baza ce sama sebe stititi od gluposti na ulazu, pa cete imati vise vremena da se bavite otklanjanjem problema, nego da ih pustite u bazu, pa ih otkrijete prekasno, pa ne znate sta je uzrok, i tako dalje. Vestacki kljucevi nisu nikad bili niti ce biti deo relacione teorije. Oni igraju ulogu pointera u proceduralnim jezicima, a pointeri u relacionoj teoriji ne postoje. Dodavanjem pointera na bazu, vi na neki nacin 'unapredjujete i dogradjujete' relacionu teoriju. Da podsetim, relaciona teorija je grana matematike, kao bulova algebra ili geometrija i trigonometrija. Sumnjam da bi neko prilagodjavao Pitagorinu teoremu u praksi, zato sto se koren i kvadrat tesko racunaju. Zasto oda prepravljamo relacionu teoriju kad ne preprsavljamo ostale grane matematike?

:-)
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column15.10.2015. u 07:21 - pre 104 meseci
Muci nas razlicite stvari, jer ti i ja ne koristimo iste baze. Ne znam kako je u MS SQL-u, ili sta vec koristis, ali problem velikih i kompozitnih primarnih kljuceva na MySQL-u, koji ja radim, je sto engine "nalepi" primarni kljuc na svaki drugi index. Kad malo razmislis, slicno verovatno radi i svaka druga baza, jer koristi primarni kljuc za pristup pojedinacnom redu. Problem je sto, ako imas kompozitni primarni kljuc od 4 kolone, onda imas taj kljuc "iskopiran" u svaki dodatni index koji si kreirao. To ne samo da trosi prost prostor na disku za svaki od tih index-a, mnogo je gore sto svako pisanje (insert/update/delete) po tabeli update-uje sve indexe, pa treba i za svaki upisati i ceo taj kilometarski primarni kljuc, a disk iops-a nema beskonacno.

S'druge strane, ta potreba da autoincrement-i budu jedan za drugim meni nema smisla. Ja imam scenarije gde imam (sa razlogom) vise serera koji imaju veliki autoincrement increment, a onda razlicit offset u odnosu na njega, sve zbog slozene seme replikacije. Sve dok imas vise od jednog servera, zaboravi na to - autoincrement treba da ti garantuje da raste. To da ce ici jedan za drugim (sa ofsetom 1) i da ce biti human readable niko ne garantuje - iskreno, ako imas milione redova, ne znam koga to briga. Nije da rucno radis.

Ja polazim sa pretpostavkom da, pored primarnog, imas jos 3-4 index-a, plus da cesto radis JOIN. I da, za constraints se slazem, njih cesto ima smisla stavljati, zavisno od podataka. Mada, ima slucajeva gde ima smisla da se izostavi i prebaci na aplikacionu logiku, ako se time stedi na performansama.... Sve zavisi od primene. Ja imam tabele od desetina i stotina miliona redova i verovatno nemamo iste optimizacije i isto iskustvao. To sto ti pricas meni ima smisla, sve dok imas do par stotina hiljada redova, ali ne na stotine miliona.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column15.10.2015. u 18:45 - pre 104 meseci
Slazem se da u praksi kolicina moze nekaa da utice na dizajn baze. Svako ima svoju muku i resava je na svoj nacin, kako misli da je nabolje. A zavisi i od sistema (Oracle, MS SQL, MySQL..), i to je tacno. Za autoinkrement si u pravu, obicno vise glavobolje nego koristi. Ja sam to pomenuo kao negativnu stvar. Ali ljudi to vole, pa neka im. Ako nam treba numeracija, kod mene se koriste 'predefined ranges' - svako dobije svoj opseg koji se ne praklapa sa ostalima, uz mogucnost izbora - da li reciklirati obrisane brojeve, ili ne.

Bazu projektujemo po relacionim principima (nisam rekao Normalizujemo, to je samo deo posla) a tabele i nisu tako velike, ima ih oko 70-80. Roditelj tabele su oko 5-10 miliona redova, a tabele deca od 50 do 250 miliona redova (neam ih mnogo na srecu). Ima nekoliko servera, koristi se i replikacija, i bulk insert, svasta. Ima nekoliko aplikacija koje pristupaju bazi istovremeno, sto desktop, sto web. Ima i oko 10,000 web korisnika koji u pikovima svi dolaze i nesto rade sa podacima. I sve je napravljeno bas kako ne bi trebalo da bude - mnogo indeksa, veliki indeksi i klucevi. Samo jedna tabela im ajednokolonski int kjuc, i ta ima oko 120 redova. Sve ostale su 2,3,4. Za FK se korsite i superkljucevi, sto dodatno trosi prostor. I sve radi. Bilo je situacija kad se ponesto izvrsavalo sporo. Ispostavilo se da su razlozi potpuno druge prirode - mali prostor za temp tabele, indeksi koji se ne osvezavaju, lose napisan front end, ili neko setovanje na mrezi i/ili samom serveru, nepravilan pristup podacima - umesto stored proc. programer sam u .NET programima sam konstruise querije i slicno. Vrlo retko je problem bio struktura tabela i indeksa. Struktura tabela je bila krivac samo kad bi zaboravili nesto potpuno, pa je trebalo da se doda u bazu neki nova potreba biznisa koji podrzavamo. I opet - radi bez problema. Znaci, moze i po kjigama, ali se treba setiti kako.

U svakom slucaju, treba ljudima omoguciti da nauce 'po knjigama', lako ce sami u praksi da obore kvalitet podataka, ako im treba.





 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6280

Sajt: pedja.supurovic.net


+1571 Profil

icon Re: Relacione baze .. spajanje preko id ili multiple column15.10.2015. u 22:40 - pre 104 meseci
Uneo sam dakle 3 puta iste podatke - 'PKB','Faktura','2015-152', bez ikakvih problema. Jedino se razlikuju vrednosti za ID. To nije dobro i to ne mozemo ostaviti front-end programeru da resava. Programi i programeri dolaze i odlaze, a baza ostaje, godinama i nikad se ne zna ko ce i kada da zaboravi da na front endu postavi neophodne uslove integriteta (jedinstvenost je uslov integriteta podataka). Da bi se ti problemi izbegli, uslovi integriteta se deklarisu na nivou tabele u bazi podataka. Ako pokusam da uspostavim uslov UNIQUE (Firma, Vrsta_Dokumenta, Broj_Dokumenta) nece mi uspeti, jer tabela vec sadrzi duplikate (triplikate :-). [/quote]

Ovde si napravio grešku u projektovanju. Ako neka kombinaciaj polja treba dabude UNIQUE onda to moraš tako i definisati. Naravno da ako nisi stavio takvo rpavilo, ono nee biti primenjivano i omogući ćeti da unosiš podatke na pogrešan način.

Ovo naravno nema nikave veze sa primarnim ključem. Isprati0 sam to što si pisao i zaključio da ti radiš sa složenim ključevima zato što si tako navikao i tebi se tzo čini kao dobar pristup. Pogrešan svakako nije, ali je nepraktičan jer prouzrokuje mnogo komplikacija i u samoj bazi i u korisničkom interfejsu. Uvek je jendostavnije raditi sa podacima koji imaju prost primarni ključ koji čini jedno polje. U najećem broju sluajeva podaci zaita uvek iimaju neku karakteristiku koja se može korsititi kao primarni ključ, ali i ako nemaju, uvek se može korsititi neka pseudo kolona koja će imati tu ulogu. Neprocenjivo je olakšanje kada podatke u tabama povezuješ preko jednog a ne preko niza polja.

 
Odgovor na temu

[es] :: Baze podataka :: Relacione baze .. spajanje preko id ili multiple column

[ Pregleda: 3174 | Odgovora: 10 ] > FB > Twit

Postavi temu Odgovori

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