Kako kontrolisati (izbjeci) duple upise?

Trebam svakodnevno importovati podatke u bazu. Broj dnevnih recorda je za sad mozda 20-30, vremenom ce vjerovatno rasti. Rijec je o podacim o telefonskim pozivima znaci da je struktura tipa:


Htio bih izbjeci da dupli insert vec postojeceg sloga. Neka ideja kako to uraditi je kreirati unique key na poljima FROM, STARTTIME, DURATION (mislim da je dovoljno), jer tesko da se moze desi da bas u istu sekundu krene poziv sa istog broja i da isto traje.

E sad, interesuje me, ako budem radio BULK INSERT i ako jedan od tih slogova u SQL komandi je vec unutra, da li ce insert kompletno puci i nece nista biti insertovano ili ce...?? Htio bih da uradi samo 'skip' i ubaci sve ostalo.
Da li je to izvodljivo i kako?

'fala

Potpis

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Ovako nesto? http://bogdan.org.ua/2007/10/1...sert-if-not-exists-syntax.html

P.S. Da, puci ce upit ako je bar jedan vec tu pa vrati error :(

Potpis

ZelenaLutrija.com - Saznajte sve o lutriji za zelenu kartu (doživotni boravak u Sjedinjenim Američkim Državama)

insert ignore ili replace .. on nece puci, obican insert ce da pukne - pritom, kod myisam-a ce ono sto je insertovao do greske ostati u bazi dok ce kod innodb-a transakcija biti "roll-back"-ovana (kako li se to kaze na srpskom) te nece biti insertovano nista

to sto ti imas je standardan problem kod cuvanja CDR-ova posto u sorsu nemas nikakav unique ID a u prenosu ne znas gde si poceo a gde stao posebno kad imas mnogo threadova koji citaju cdr-ove i rokaju u bazu .... ja licno nisam video nijedno zadovoljavajuce resenje do sada ... ili imas duplikate, ili je sporo ili gubis pozive ... jedino ispravno resenje je da gateway direktno roka podatke u bazu .. to sam video kod dosta resenja, i kod cisco gateway-a i kod drugih resenja .. gde rokaju podatke direkt na mysql ..

sto se tice "bas u istu sekundu" ... jedna bivsa firma, mali promet .. oko 200 miliona minuta mesecno - ~3% poziva pocinje "iste sekunde" :) oni su imali sistem koji roka direkt u bazu tako da nisu imali taj problem ali su vadili neke statistike (oko pikova u cuda) i oko 3% poziva (ne mogu da se setim cifre tacne ... dal 2.8 ili 3.5 .. nije ni bitno) ima isti starttime i duration :D ... objasnjavao mi je voip ing. tamo zasto ... al ima tome mnogo godina a memorija mi odavno nije kao sto je bila :)

sa unique kljucem na from, to, starttime, duration ... definitivno si ga zabo ... ako je isti start i to .. "to jeste duplikat" :)

Ono sto je cudno je da ti imas taj problem na 20-30 CDR-ova dnevno ... dakle cuvas log svog voip telefona na primer .. kakav god da mu je log mozes da ga "povuces pa obrises" tako da ne znam sto tu imas problem sa duplikatima?

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

^^^ Radius server ili šta već koriste ne razmišlja puno nego samo upisuje u bazu a NAS se nekada zbuni pa pošalje duple podatke jer misli da ih ovaj nije primio, ima interni BUG ili ko zna zbog čega... ...

Što bi rekli ljudi "NAS is broken" :)

Imao sam sličan problem ali je postavljanje UNIQUE-a riješilo isti...

Potpis

Oki, INSERT IGNORE radi posao. Ono sto je duplo u BULKu ignorishe, ostalo pa ubaci.

Nemam ja problema, ali u fazi sam razvoja aplikacije koja uvozi CDR-ove sa VoIP provajdera i razdvaja ih na korisnike na osnovu 'from' polja. Ako bi mi u nekom momentu puko import zelim da mogu da ga odradim ponovo ali da ne brinem hoce li biti duplih unosa ili ne.

I dok ja dodjem do tog 'malog prometa' procice ... tehnologija :)

Hvala svima.

Potpis

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

U zavisnosti od switcha koji se koristi, u vecini sluchajeva bi trebalo da postoji mogucnost da u cdr udju i josh poneki podaci, sequence number, inbound trunk group i member, outbound trunk group i member ... to su sve podaci koji koriste u takvim sluchajevima. Naravno, zavisi od konfiguracije konkretnog sistema sa kojim radish.

yup, odredi da li oces replace ili insert ignore .. zavisno od toga sta hoces da postignes .. insert ignore je brzi (posto ne radi nista :D ) od replace-a

sto se "malog prometa" tice .. to je bas bas malo za "trgovce" .. za one koji rade originaciju i terminaciju je to verovatno velika brojka .. ali za ove koj samo rade rutiranje i skidaju kajmak je to sica :) ... fora je sto je "ruterima/trgovcima" bitno da imaju sve zive statistike posto u zavisnosti od slr placaju ili ne placaju terminaciju, odredjuju rute i slicno ... ako se ja dobro secam (ali sad je moguce da izmisljam posto je bilo daaaaaaavno), ruteri su to pucali kroz neki interface u mysql tabelu koja nije imala indexe uopste, to je alex citao nekim php-om i presipao na drugi server u tabelu sa indexima (i to ogromnim secam se da smo imali probleme sa performansama inserta) i onda je opet neki peti php to citao i generisao neka cuda na nasem lokalnom mysql serveru ... sve u svemu bio je neki dobar razlog za celu tu komplikaciju a dok je to namestano alex (lik koji je sve to radio / ludi ukrainac koji je pre toga radio za cisco kao sef nekog dev tima) je non stop bio na telefonu sa likovima iz cisca posto im je nasao cudo i karate bagova u sistemu ...

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/