DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > PHP
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

PHP PHP aplikacije, Smarty, PEAR

Odgovori
 
Alati teme Način prikaza
Staro 07. 11. 2012.   #1
spezia
član
Certified
 
Datum učlanjenja: 21.05.2010
Lokacija: Nis
Poruke: 54
Hvala: 24
450 "Hvala" u 10 poruka
spezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished road
Default 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?
spezia je offline   Odgovorite uz citat
Staro 07. 11. 2012.   #2
webarto
expert
Grand Master
 
Avatar webarto
 
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
webarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished road
Default

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.
__________________
Github // LinkedIn // PHP // ZCE // Stackoverflow PHP // Site5 Web Hosting
webarto je offline   Odgovorite uz citat
"Hvala" webarto za poruku:
Staro 07. 11. 2012.   #3
mangia
Pukovnik u penziji
Grand Master
 
Datum učlanjenja: 11.10.2006
Lokacija: Banjaluka, BiH
Poruke: 941
Hvala: 209
585 "Hvala" u 137 poruka
mangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoro
Pošaljite poruku preko MSN za mangia Pošaljite poruku preko Skype™ za mangia
Default

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
__________________
mangiaphoto | BLOGERAJBLOG | ServerAdminBlog
mangia je offline   Odgovorite uz citat
"Hvala" mangia za poruku:
Staro 07. 11. 2012.   #4
djipko
član
Certified
 
Avatar djipko
 
Datum učlanjenja: 03.10.2006
Poruke: 96
Hvala: 27
44 "Hvala" u 26 poruka
djipko is on a distinguished road
Default

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...
djipko je offline   Odgovorite uz citat
"Hvala" djipko za poruku:
Staro 07. 11. 2012.   #5
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 08. 11. 2012.   #6
spezia
član
Certified
 
Datum učlanjenja: 21.05.2010
Lokacija: Nis
Poruke: 54
Hvala: 24
450 "Hvala" u 10 poruka
spezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished roadspezia is on a distinguished road
Default

Citat:
Originalno napisao mangia Pogledajte poruku
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
U mojoj knjizi pise da je bolje koristiti MyISAM jer se pretrazivanje podataka radi brze, InnoDB je sporiji pa treba voditi racuna gde ga koristiti (samo po potrebi - tipa transakcije).
E sad knjiga je stara par godina

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
spezia je offline   Odgovorite uz citat
Staro 08. 11. 2012.   #7
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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..
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 08. 11. 2012.   #8
mangia
Pukovnik u penziji
Grand Master
 
Datum učlanjenja: 11.10.2006
Lokacija: Banjaluka, BiH
Poruke: 941
Hvala: 209
585 "Hvala" u 137 poruka
mangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoro
Pošaljite poruku preko MSN za mangia Pošaljite poruku preko Skype™ za mangia
Default

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.
__________________
mangiaphoto | BLOGERAJBLOG | ServerAdminBlog
mangia je offline   Odgovorite uz citat
"Hvala" mangia za poruku:
Staro 09. 11. 2012.   #9
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum


Vreme je GMT +2. Trenutno vreme je 18:41.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.