DevProTalk

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


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 20. 04. 2007.   #1
Dragi Tata
dinosaurus
Master
 
Avatar Dragi Tata
 
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
Dragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoro
Default Brisanje većeg broja slogova iz MySQL baze

Recimo da imam tabelu i da korisnik može da vrši neke prilično složene (i skupe) pretrage nad tom tabelom, a ako mu padne napamet i da izbriše sve rezultate neke od tih pretraga.

U prvom prototipu, jednostavno pamtim id-ove svih slogova koji su pronađeni pretragom i onda ako korisnik tako odluči u jednoj petlji brišem slogove po id-u. Ovo naravno radi, ali gledam da to uradim malo efikasnije/elegantnije. Koliko kapiram, MySQL podržava IN sintaksu, pa bih mogao nešto kao:

DELETE FROM tabela WHERE id IN (1, 5, 8...)

Koliko vidim, jedino ograničenje za IN je max_allowed_packet, ali ne znam kako bi ovo uticalo na performanse.

Da li bi "prepared statement" možda bilo bolje rešenje?

Mišljenja, ideje?

Hvala unapred.
Dragi Tata je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #2
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Default

Koliko znam ne postoji brži način, osim ako ne brišeš celu tabelu (tada je AFAIK TRUNCATE brži).

Mislim da te max_allowed_packet promenljiva (podrazumevano je 16MB) ne treba da brine, osim ako nemaš nekoliko miliona id-ova u IN klauzuli.
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #3
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

koliko ja znam IN koristi indexe... koristim ga vrlo cesto upravo za te "delete all checked" operacije i nisam nikad imao nekih problema, niti problema sa perfomansama...cak mislim da je to brze od petlje koja brise jedan po jedan rekord cak i kad je sql izraz prepared (sto do nedavno nije moglo iz php-a, pa sam zato i navikao na IN), jer se ipak sve odvija interno u mysql-u...

u svakom slucaju sa indexiranom tabelom IN radi vrlo lepo..
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #4
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

A dodatna tabela (idpretrage, id) ti ne odgovara?
jablan je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #5
Dragi Tata
dinosaurus
Master
 
Avatar Dragi Tata
 
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
Dragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoro
Default

@Petar, ivanhoe:

Hvala, to mi savetuje i DBA.

Citat:
Originalno napisao jablan
A dodatna tabela (idpretrage, id) ti ne odgovara?
Misliš da rezultate pretrage čuvam u posebnoj tabeli, pa ako korisnik reši da briše da udarim Delete po subqueriju iz te tabele?

Interesantan pristup, samo je problem što obično ima mnogo pretraga a malo brisanja. Dokle da držim te pretrage u bazi i kad da ih brišem? Mislim da temp tabela ne dolazi u obzir jer korisnik vrši pretragu tokom jedne (http) konekcije a briše u drugoj.
Dragi Tata je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #6
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Citat:
Originalno napisao Dragi Tata
Misliš da rezultate pretrage čuvam u posebnoj tabeli, pa ako korisnik reši da briše da udarim Delete po subqueriju iz te tabele?
Da, da. Mislim, ne tvrdim da je to rešenje bolje, samo ga navodim kao jedno od mogućih.

Što se brisanja tiče, sve zavisi od prirode aplikacije, količine podataka, učestalosti brisanja i punjenja itd. Jedno od rešenja je da se koristi timestamp i da se brišu sve pretrage starije od nekog određenog intervala.
jablan je offline   Odgovorite uz citat
Staro 20. 04. 2007.   #7
Dragi Tata
dinosaurus
Master
 
Avatar Dragi Tata
 
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
Dragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoro
Default

Kao što rekoh u mom slučaju ima mnogo više pretraga nego brisanja, pa se bojim da tako nešto ne bi bilo uputno, ali generalno gledano nije loša ideja.

Thx.
Dragi Tata je offline   Odgovorite uz citat
Staro 21. 04. 2007.   #8
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
701 "Hvala" u 194 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

Mislim da je ovo prvo resenje optimalnije po nacinu upotreba indexa od ovog sa subquerijem. Koliko se secam literature (nisam preterano koristio subquerije u praksi), do MySQL-a 5.1 optimizacija je bolje funkcionisala kada se ne koriste podupiti.

Ukratko:

Kôd:
delete from foo where id in (1,2,3)
je optimalnije nego

Kôd:
delete from foo where id in (select id from temp_table)
.

Koga ne mrzi moze i da proba sa malo vecim brojem recorda i odgovarajucim explainom
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 21. 04. 2007.   #9
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

^Jeste, ali šalješ mnogo više podatka preko "žice" do baze ako je IN lista duga.. Petlja je najlošije rešenje, jer za svaki ID moraš ponovo da se konektuješ na bazu - connection pooling u takvom slučaju je verovatno obavezan, ako su performanse bitne.

Jedno od rešenja jeste da koristiš upit:

DELETE FROM t1 WHERE ID IN ( .. originalni upit [izmenjen da selektuje samo ID].. ).

Čime si izbegao da šalješ gomilu ID-ova u IN klauzi, ne treba ni pomoćna tabela, itd. Ovako može jer nema potrebe da navodiš "novu" listu ID-ova u IN klauzi, pošto, čini mi se, reče da brišeš sve zapise koji su prethodno bili vraćeni nekim upitom - samo ponovi taj isti, malo izmenjen, SELECT u podupitu za IN. Ako još možeš da taj upit izraziš sa prepared statement-om, ne izgleda mi loše rešenje, posebno što bi baza kod brisanja već mogla da ima keširane potrebne ID-ove nakon prvog upita.

Treba probati
__________________
Commercial-Free !!!

Poslednja izmena od degojs : 21. 04. 2007. u 04:08.
degojs je offline   Odgovorite uz citat
Staro 21. 04. 2007.   #10
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

mozda neka pametnija baza, mysql ce taj originalni upit da ponovi jer query nije identican (mora do poslednjeg karaktera da bude isti da bi mysql koristio cache)
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Odgovori



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

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Zastita mySQL baze SadClown SQL baze podataka - Sponzor: Baze-Podataka.net 5 21. 10. 2007. 22:38
Brisanje velikog broja spam komentara u WordPressu MarkoMarko Web aplikacije, web servisi i software 5 10. 04. 2007. 17:34
Čime testirate MySQL baze? dee SQL baze podataka - Sponzor: Baze-Podataka.net 7 11. 10. 2006. 00:48
Eksport i import MySQL baze Dragan Babić SQL baze podataka - Sponzor: Baze-Podataka.net 18 13. 08. 2006. 13:28


Vreme je GMT +2. Trenutno vreme je 01:37.


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.