[ dzigilibonglica @ 27.01.2012. 16:03 ] @
Znači situacija je sledeća:

Radi se novi projekat, biće velike tabele, i mnogo upita nad njima, i ideja je da se sve to lepo optimizuje maximalno, što hardwerski što kroz setovanja servera,
ali naravno akcenat će biti na dobro projektovanoj bazi, odnosno NORMALIZACIJA

Table1
Field 1: Primary Key1
Field 2: VarChar(..)

Table2
Field 1: Primary Key2
Field 2: VarChar(..)


Table X
Field 2: Primary KeyX
Field 2: Foreign Key Table1
Field 3: Foreign Key Table2

Znači ideja je da nema duplih podataka i da baza bude Normalizovana do kraja.
Nad tabelom X bi bio ViewX koji bi prikazivao Vrednosti VarChar iz referenciranih tabela.



E sada za potrebe lakšeg razumevanja onoga što ću da Vas pitam, napravio sam banalan primer:

Table TImena
============
ID int(11) PK
Ime varchar(30)


Table TPrezimena
================
ID int(11) PK
Prezime varchar(45)


Table TLjudi
============
ID int(11) PK
Imena_ID int(11)
Prezimena_ID int(11)

Tabele se uvezane ovako:




I imam View VLjudi koji bih koristio umesto tabele.:
Code:
CREATE VIEW `VLjudi` AS
SELECT Ime,Prezime 
FROM TLjudi, TImena, TPrezimena 
WHERE TLjudi.Imena_ID=TImena.Id AND TLjudi.Prezimena_ID=TPrezimena.Id;




I situacija je sledeća sa podacima:
Code:

mysql> SELECT * FROM TImena;
+----+------+
| ID | Ime  |
+----+------+
|  3 | Mika |
|  1 | Pera |
|  2 | Žika |
+----+------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM TPrezimena;
+----+---------+
| ID | Prezime |
+----+---------+
|  2 | Pantić  |
|  1 | Šoić    |
+----+---------+
2 rows in set (0.00 sec)

mysql> SELECT * FROM TLjudi;
+----+----------+--------------+
| ID | Imena_ID | Prezimena_ID |
+----+----------+--------------+
|  1 |        1 |            1 |
+----+----------+--------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM VLjudi;
+------+---------+
| Ime  | Prezime |
+------+---------+
| Pera | Šoić    |
+------+---------+
1 row in set (0.02 sec)



Znači, ideja je i da u pravom projektu, umesto tabele sa gomilom vrednosti koje se ponavljaju, ja imam tabelu gde su sva polja Foreign Key-evi (Sem Primarnog, normalno), i imao bih view koji bi tu tabelu prikazivao kako treba.
Sve super sve sjajno sve bajno, ali na ovom primeru.

U stvarnosti bi umesto dva referencirana polja, bilo tridesetak polja, pa to pravi gimnastiku kada su u pitanju Insert i Update.


Pitanja
1) Da li je moguće uraditi
Code:
 INSERT INTO VLjudi (Ime,Prezime) VALUES ('Mika','Pantić')
znači ime i prezime postoje u referenciranim tabelama

2) Da li je moguće uraditi
Code:
 INSERT INTO VLjudi (Ime,Prezime) VALUES ('Marko','Marković')
ime i prezime NE postoje u referenciranim tabelama, i morao bi da se u njih radi INSERT


Predpostavljam da je odgovor NE, i da MySQL ne može baš toliko da se automatizuje (jer sam probao ove Query-je),

3) Da li bar postoji mogućnost da se podigne Trigger nad Ovim View-om u koji bih ja mogao da gurnem kood koji će pešaka kroz SQL kood proveriti da li ima, i ako treba dodati, pa onda gurnuti Key-ve u tabelu.


Ako ništa, radiću kao i do sada, kroz moj kood u aplikaciji, prvo će se raditi sve provere pa insertovati Foreign Key-evi u tabelu...
samo je to smor, i nad 30-tak polja, mnogo je to gimnastike, gde god imam insert i update, to je gimnastika na svakoj formi.

Znači jel može to ikako da trči na bazi, odnosno da mi se View ponaša kao tabela?

Nadam se da ste razumeli šta Vas pitam,
Pozdrav :) !




[Ovu poruku je menjao dzigilibonglica dana 27.01.2012. u 17:45 GMT+1]

[Ovu poruku je menjao dzigilibonglica dana 27.01.2012. u 18:16 GMT+1]
[ mret @ 27.01.2012. 16:42 ] @
Citat:

Pitanja
1) Da li je moguće uraditi
Code:
INSET INTO VLjudi (Ime,Prezime) VALUES ('Mika','Pantić')


-- NIJE! View moze da se insertuje samo nad jednom tabelom (ako je naravno MySQL u pitanju). Ubacivanje podataka kroz "kompozitni" View je tesko ili nikako izvodljiv.
Citat:

znači ime i prezime postoje u referenciranim tabelama
2) Da li je moguće uraditi
Code:
INSET INTO VLjudi (Ime,Prezime) VALUES ('Marko','Marković')
ime i prezime NE postoje u referenciranim tabelama, i morao bi da se u njih radi INSERT

-- isto je vrlo nemoguće ili nije pametno
Citat:

Predpostavljam da je odgovor NE, i da MySQL ne može baš toliko da se automatizuje (jer sam probao ove Query-je),

3) Da li bar postoji mogućnost da se podigne Trigger nad Ovim View-om u koji bih ja mogao da gurnem kood koji će pešaka kroz SQL kood proveriti da li ima, i ako treba dodati, pa onda gurnuti Key-ve u tabelu.

-- nije pametno resenje jer ces ovo tesko da odrzavas, mislim da ces brzo doci na nivo upetljavanja, pa ako vec radi ispocetka uradi ga kako treba.


Da dam neki zakljucak - ovo ti nece piti vode lepo je kada je dosta stvari normalizovano (ili ako vec hoces - sve), ali treba u svemu imati meru, jer akademske stvari tipa "zatvarac skupa funkcionalnih zavisnosti" i totalno izbegavanje redundanse je pogresno navodjenje u praXi. Ja sam radio na brdo aplikcaija i nigde nisam video ovakav koncept sa imenom i prezimenom (nadam se da su ovo samo test podaci), a pogotovo je z.....no da kroz neki mehanizam kontrolises da li nesto postoji od vrednosti ili ne i da ubacujes u druge tabele.


Moras da pri projektovanju nadjes meru koja ce uslovno receno zadovoljiti sve strane.
Mislim da ces se ovde brzo zapucati ako zelis bas ovako da projektujes sistem.

View moze da se ponasa kao tabela u nekom smislu ako predjes na ORACLE bazu (PK, FK....).
Ako sam bio od neke ideje za ispravljanje, drago mi je.


[ dzigilibonglica @ 27.01.2012. 17:05 ] @
Hvala na odgovoru,
ovo je banalan primer naravno, u praksi su podaci drugog tipa.


Normalizaciju i radimo da bi se neke stvari ubrzale maximalno, a ne zbog pedantnosti.
U pitanju je obrada nekoliko desetina miliona slogova i vrlo često umesto:

Code:

 SELECT DISTINCT Naziv FROM TNeka_velika_tabela_od_par_miliona_slogova


mnogo brže je uraditi
Code:

 SELECT Naziv FROM TNeka_mala_tabela_sa_par_stotina_naziva_ciji_su_key-vi_u velikoj_tabeli


Pretpostavio sam da ne može, šteta...
a i bilo bi mnogo kada bi i to moglo
;)
[ bogdan.kecman @ 27.01.2012. 23:37 ] @
Citat:
dzigilibonglica: 
Normalizaciju i radimo da bi se neke stvari ubrzale maximalno, a ne zbog pedantnosti.


Normalizacija u velikom procentu USPORAVA stvari a ne ubrzava!!!
Poenta normalizacije je INTEGRITET, ne brzina.
Vrlo cesto se u optimizaciji radi denormalizacija dela baze kako bi se dobilo na brzini.

Inace, cela prica sa view-ovima nema pretarano smisla, ni za select ni za insert. Posebno ako zelite da dobijete na brzini! MySQL ne zna sta je to materijalized view tako da se view kao takav izvrsava prilicno "obicno" te nikakvog ubrzanja nema. Jedini razlog za koristenje istih je "skrivanje underlying tabela koje cine podatke iz tog view-a" ali "od koga ih krijete i zasto?". Bolje u aplikaciji napravite poseban layer koji radi "vadjenje" i "smestanje" tih podataka (i napisite ga sami, nemojte da koristite neke pateticne ORM sisteme koji ce tek da uspore celu pricu) nego da se zezate sa view's i stored procedures.

Ovo je naravno moje licno misljenje i iskustvo, ne "zvanican stav mysql konsalting tima" posto se on donekle razlikuje ... no to sad ima mnogo vise veze sa politikom i manje sa performansama :)