|
Foreign keys u bazi ili pisanje koda
Imamo 2 nacina za brisanje podataka iz baze..
1) Ako imamo 4 tabele gde su tri povezane sa prvom preko spoljnih kljuceva, ako zelimo da obrisemo podatak , npr nekog korisnika automatski se brisu njegovi podaci i u ostalim tabelama... Znaci pisemo samo jedan upit za brisanje iz prve tabele a ostale 3 se automatski brisu( mislim na odredjene redove ) 2) pisanje php koda, gde ce obrisati sve ove podatke u 4 tabele Znaci treba nam 4 upita... Ja sam do sada pisao na drugi nacin. Sta je savet i dobar nacin - prvi ili drugi, tacnije da li prvi ima mana ili neka ogranicenja kada ga upotrebljavati a kada ne...? Koliko vidim nije samo povezivanje samo za Delete vec ima opcija i za Update. Jel koristi neko ovo? |
Najbolje da testiraš i vidiš šta je brže i koliko. Ako nema neke razlike, radi kako ti je lakše. Nema prvi ili drugi, sve zavisi od konteksta.
Nemoj optimizovati ono što ti ne pravi problem. |
Mislim da se trebaš držati prve verzije (pošto InnoDB preuzima primat) i da samo definišeš CASCADE za ON DELETE i ON UPDATE
|
Ja sam licno poklonik sledece filozofije - moram imati *JAKO* dobar razlog da bi nesto brisao kao deo standardnog funkcionisanja aplikacije - kao deo standardne funkcionalnosti imam dodatnu kolonu/polje 'deleted' (ili 'removed' ili sl.) i kad se to dogodilo, i samo nju setujem.
Ako ti je prostor problem - neki cron job cisti sve obrisane s vremena na vreme. Inace po meni - optimizovanje SQL upita je apsolutno poslednja stvar koju treba da radis kad si iscedio sve ostale mogucnosti (server je podesen kako treba i baza je podesena kako treba, tabele imaju smisla i indeksirane su kako treba, kesiranje radi kako treba i diskriminatori imaju smisla, disk i/o mi nije problem, skinuo sam crnu magiju sa servera... e pa tek onda friziram sam SQL). Dakle kao sto rece Webarto... |
Prvi nacin je laksi i sigurniji za programera i ne zahteva da programer misli o svakoj relaciji u bazi... isto kao foreign keys i stored procedures, to je superioran nacin za pravljenje velike i ozbiljne baze... tako bar kazu u knigama :)
Sa druge strane, foreign keys znaju da smaraju kod importa i exporta podataka, i uopste menadzovanja baze, kao i kod shardinga... za male (uobicajene) projekte koje radi mali (i strucan) tim koji zna sta je gde u bazi su FK, referencijalni integritet i kaskadna brisanja samo overhead. Ja licno ih ne koristim skoro nikad... Moje resenje je da se sav pristup bazi radi preko model klase i da onda model zna sta treba da obrise, kojim redom treba da dodaje podatke u koje tabele i sl. Tako isto dobijes lagodnost da podatke brises pozivom samo jedne metode bez mnogo razmisljanja, ali je kontrola i logika u kodu, pa je lakse uhakovati dodatne provere ili prepraviti nesto u bazi kad je hitno... Inace, nisi u pravu da za prvi nacin treba samo 1 upit, tu se isto izvrsavaju 4 upita na bazi, samo stedis na prepare-ovanju SQL za ostala 3 upita |
Citat:
E sad knjiga je stara par godina :1074: Sta se desava ako zelim da obrisem samo podatak (red) iz tabele 4... Jel ima uticaj na ostale tabele? Nekako je prvi nacin laksi ali sa 2 nacin imam vecu kontrolu (mada je pitanje da li mi treba takva kontrola, verovatno vrlo retko)... Mozda sto nisam radio sa prvim nacinom pa mi deluje nekako opasno. Npr. Kada pogledam kod u drugi nacin, tacno vidim sta se desava, ovako treba da pamtim kada se nesto obrisalo da je to bilo automatski (npr imam 200 tabela). U svakom slucaju hvala na odgovorima :1081: |
Ne mozes da obrises podatak koji je FK nekoj drugoj tabeli, to i jeste poenta ref. integriteta..
Nema razloga da se plasis da koristis CASCADE, baza to radi u transakciji i sasvim je pouzdano. Takodje ako imas FK onda ce te spreciti da obrises pogresan podatak i slicno, znaci to je sigurno pouzdaniji pristup, nema sanse da zeznes nesto slucajno zbog buga u kodu. Ali kao sto rekoh, problem je sto moras da vodis racuna o redosledu operacija nad tabelama i onda je ponekad smor uraditi neku brzu intervenciju na bazi... obicno kad ti se bas zuri.. |
MyISAM jeste brži kod čitanja ... I tu staju sve njegove prednosti...
Pisanje 1 upita je daleko praktičnije nego pisanje 3,4,5,6,... itd... I kao što reče ivanhoe nema potrebe da komplikuješ.... Naravno, moraš voditi računa da korištenjem MyISAM-a transakcije padaju u vodu pa samim tim i ideja o 1 upitu za brisanje. |
To za brzinu myISAM je vazilo pre par godina, sad nisam vise siguran? Jel zna neko za neki benchmark koji je radjen posle 2010?
Jedina prava prednost myIsam (bar meni) je fulltext search... sto je ponekad velika prednost, jer ti za vecinu sajtova treba neki search :) |
| Vreme je GMT +2. Trenutno vreme je 04:14. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.