SORRY netycia i privata reply padariau :)

    Na tada trynimas gal ir logiska jei dedi kitur irasa :) ta prasme kaip as tai vadinu atliekamas duomenu kopijavimas i kita lenta :) nors cia greiciausiai daroma del performance, kad nesikauptu per daug irasu lentoje - saltinyje.

    Manau bus dar viena problema, daznai trinant reiks daryt lentos shrinkinima  (mysql gal tai kitaip vadinasi si operacija, koks nors optimize ir pan... o daryti tai po kiekvienos operacijos ner gerai) nes tai itariu ir gali tormozyt, o ne geriau tada butu visdelto dadeti pozymi, pvz.:

> Turiu lentą:
> Numeris,
> e-meilas,
> Tekstas,
> Sukūrimo data
    processed 1/0 - INDEXED

    Tada emimo threadai ima viska kas ne processed ir po processinimo stato veliava kad processinta, o trinama pvz i para karta kadanors nakti kada nieks nevyksta, na nes cia jovalas darysis su MySQL lentos failais ir tai gali manau itakoti performance -  kai daug visko trinama failu sistemoje, vistiek teks shrinkint, bet lenta laikas nuo laiko daug trinant reiks aptvarkyt su siom funkcijom nes kitaip tormozys ir del to manau... tada tranzakcija  tik tam laikui kol vyksta paemimas ir trynimas ar pozymio uzstatymas manau yra teisingas variantas, su delete darai tiesiog daug siuksliu failinej sistemoj.

Profilaktinis job kas para butu kazkas tokio tada:

tranzakcijos pradzia

DELETE FROM lenta WHERE processed = 1

tranzakcijos commit

OPTIMIZE TABLE `lenta`



----- Original Message ----- 
From: "NicMC" <jzs@freemail.lt>
Newsgroups: omnitel.programming
Sent: 2011 m. gruodžio 7 d. 16:18
Subject: Re: Need nuomonės iš šono - DB


> Nu žiūrėk, pabandysiu duoti analogišką pavyzdį kas bandomas išburt. 
> Pabrėžiu iš anksto, su jokiais emailais tai neturi nieko bendro, bet 
> kaip pavyzdys - tiks puikiai.
> 
> Turiu lentą:
> Numeris,
> e-meilas,
> Tekstas,
> Sukūrimo data
> 
> Softo užduotis - paimti vieną eilutę, išsiųsti laišką, kitoj lentoj 
> padėti rezultatą (išsiųstas ar ne). Softas threadintas, vienu metu 
> veikia 6 threadai (nu, geresniuose servuose iki 16).
> Pradiniam variante buvo txt failas su duomenimis, failai kilnojami 
> rankom ir t.t. Pirmas updeitas - padaryta DB, softas jungiasi prie DB, 
> kiekvienas threadas pasiima vieną eilutę, ją ištrina, kitas threadas jau 
> gauna kitą eilutę. Performance padidėja - lagino vis tik iš failų 
> skaityt po eilutę.
> Poreikis didėja, atsiranda antras servas su tokiu pačiu softu, tik 
> jungiasi į pirmo servo DB. Dar vienas. Ir dar. Šiuo metu - jau 8 servai, 
> threadų iš viso arti 50. Užkrovus į lentelę 150000 įrašų, bendras 
> performance jau krenta. Nu, būtų dzin - 150000, tai čia dienos norma 
> jiem. Bet kas dieną kilnot - užkniso.
> Shared networked queue demoną daryt noro mažai, tikėjaus su DB išspręst, 
> bet panašu, kad nerealu.
> 
> P.S. Su meilais tas neturi tikrai nieko bendra.
> 
> On 2011.12.07 16:03, Jornada Del Muerto wrote:
>> Sveiks,
>>
>> Nezinau man tai nesiziuri sitai, ipac delete, ne paprasciau butu
>> spresti su verslo logika, pvz. sukurt lenta tipo
>>
>> table_name_locks -------- _userId PK _recordId PK date DATETIME -
>> tipo lockijimo data del visa ko
>>
>> (cia toks iprotis laukai kurie tiesiogiai nerodomi UI turi priekyj
>> underscore _ simboli, o kurie rodomi ne, tada ivairus db selectu
>> isvedimo UI komponentai turint 1 konfiguruojama bool parametra
>> showUnderscores true/false gali juos rodyti arba ne, tokio standarto
>> paprastai laikausi db projektuodamas ir UI komponentai taip padaryti
>> kad i tai atsizvelgia, del to parasius paprasciausia select * from
>> blabla UI komponentas rodys tik laukus kuriuos turi matyt useris)
>>
>> Nu ir jei kazkoks irasas paimamas redagavimui tai darai cia insert
>> jei jo dar nera, na jei bus ir darysi errora mes.
>>
>> Ir po to useriui loadini irasus tipo:
>>
>> SELECT * FROM table_name WHERE _recordId IN ( SELECT _recordId FROM
>> table_name_locks WHERE _userId = XXX )
>>
>> Ta prasme krauni butent siuo selectu tai ka jis redaguoja tada jei
>> luzteli kazkas ir sekanti kart eis sis selectas vistiek tures tai ka
>> paemes redaguot, o kada paredaguoja tada is table_name_locks tiesiog
>> pasalini irasa ir ji gali imt kiti.
>>
>> Tuo paciu gali kiti useriai matyt kas ka redaguoja, kad nevargtu
>> jamt, pvz daro paieska:
>>
>> SELECT T.*, U.name userName, TNL.date FROM table_name T LEFT JOIN
>> table_name_locks TNL On T._recordId = TNL._recordId LEFT JOIn (useriu
>> table .... ) U
>>
>> WHERE (... blabla salygos...)
>>
>> ANYWAY Duomenu naikinimas su DELETE yra blogas dalykas ...
>>
>> P.S. Siulyciau is viso vengt technologiniu sprendimu, na kaip tavo
>> atveju tam tikra biznio logika nori uzkart tranzakcijoms.. cia toks
>> naujos kartos programmeriu budas viska sukart ant technologiju, bet
>> daznai poto tai brangiai kainuoja in long run... siuo atveju
>> nenaikini duomenu ir elementari logika susitvarkytu graziai su
>> viskuo.
>>
>> JDM.