:) na del neveikimo kalbos negali buti ...:) esme tik kaip ir kiek bus pinigu toks ir bus sprendimas... :) ner kazkaip noro dirbti "For food":) On 2011.05.01 14:18, Jornada Del Muerto wrote: > Bet tai ir tures atitinkama daikta kiek skiria :) paprastai ant tokiu dalyku nesutaupysi per daug, veliau kish pinigus i to daikto problemas del pigios realizacijos ar tai kazkokia intensyvia prieziura ar net darbo vieta teks kurt arba poto perdarinet is naujo... O dar ir informacija ne siaip bile kazkokia, o susijusi su pinigais - rimtai turetu ziureti :) > > P.S. > Cia kaip su vienais susiduriau, kazkas suxalturino e-shopa vienai imonei, po to isvaziavo i uzsieni laimes ieskot ir pamirso :) o ten trivialus dalykai nedabaigti, va po to pasiuliau kad jau geriau koki OpenCart susimestu vietoj investavimo pinigu i kazkieno sukurta, niekam nezinoma, be jokios dokumentacijos ir gan didelia e-shop sistema, o juokingiausiai kad ant galo valdzia ju pasake kad ner pinigu tam ir pats tos imones vadybininkas bandyti paleist saita ant opencart pradejo :) > > Na ten prekiaujanti tam tikra iranga imone, pajamos tai is pardavimu pas juos, bet valdziai dzin kaip jie vyks :) kad dalis e-shop neveikia ir t.t... cia kaip sedeti ant sakos ir ja pjauti :) pinigu nera - nes prastai eina prekyba - prastai eina prekyba nes e-shop ne pilnai veikia, o del to dalis klientu gali neuit kitur, o poto kas buna? nera pinigu ;) > > > > "OgOwAu"<naujasdizainas.lt@gmail.com> wrote in message news:ipj894$4q8$1@trimpas.omnitel.net... >> Na finansu skiria, bet ne tiek kad galima butu visa servisa sukurti. >> >> On 2011.04.29 14:34, Jornada Del Muerto wrote: >>> Nu tokie projektai nesidaro uz kelis litus ir jei pataupoma tai poto jauciasi ant rezultatu. Jei e-shop nu tai darai koki web duomenu interface ar webservice, sandelio pusej kad nelagint sandelio pacio per daug savo kokia tarnyba kuri sinchronizuoja ir viskas. >>> >>> "OgOwAu"<naujasdizainas.lt@gmail.com> wrote in message news:ipcgqh$qbu$1@trimpas.omnitel.net... >>>> Dekui uz mintis, bet realiai jauciu darysiu shop kaip pagrindinis >>>> likuciu saltinis, o jau sandeliai tegu siurbiasi sau info kas yra like... :) >>>> SKU, QTY ir tegu imasi is shopo info, realiai kito kelio nelabai gausis. >>>> Nes taskai Amerika, Arabai, Rusija, Vokietija. >>>> O dar dasideda ir netik Win o Macines ten programulkos kurios dar >>>> nemaciau, tai bus linksma. >>>> >>>> On 2011.04.28 14:46, Jornada Del Muerto wrote: >>>>> Hmm... Nu o kodel? Jeigu taip pasvajojus, keli variantai i galva sove: >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> 1 Variantas - MSSQL gali prisilinkint MySQL ir kazka su juo daryt kiek zinau. >>>>> ------------------------------------------------------------------------------------ >>>>> 1.1 Statom tarp siu 2 tasku VPN ar koki kita protokola kur su kuriuo 2 nutolusios viena nuo kitos masinos tampa viename LAN, net jeigu jos ir stovi kiekvienoje vietoje vidiniam tinkle ir neprieinamos is interneto tiesiogiai. >>>>> >>>>> 1.2 Linkinam prie MSSQL MySQL serveri ir rasom duomenu apsikeitima, ar tai T-SQL koks nors JOB ar dar kazkas. >>>>> >>>>> >>>>> P.S. Kaip sakiau cia pasvajojimas, cia toks mikrosoftinis variantas labiau, vat idomu ar greiciu, pralaidumo ir t.t... pakaktu tokiam dalykui. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> 2 Variantas - Webservisas - jo pagalba pakitimu sinchronizavimas. Galimos dvejopos realizacijos priklausomai nuo situacijos, bet kuriuo atveju pries toki funkcionaluma leidziant reik, kad abiejuose pusese tuo metu butu vienodi likuciai. >>>>> ------------------------------------------------------------------------------------ >>>>> >>>>> ### 2.1 Webservisas E-Shop puseje - sandelys atidavineja likucius. Reiskia, kad sandelys bus aktyvi puse ir didesnis darbo stabilumas garantuojamas e-shop'ui - nes jam niekur kreiptis nereikes net jei sandelys bus offline ar dingus interneto rysiui su ta salimi jis veiks su turima informacija. >>>>> >>>>> 2.1.1 Sandelyje vykstant pakeitimam jie irasomi i pvz kazkokia db lentele, kur taip pat uzdedamas jiems pozymis, apie pakeitimo statusa ar jis perduotas e-shopui ar ne; >>>>> >>>>> 2.1.2 Tada statyt kokia nors tarnyba, pvz WinNT service ir ji kas kazkiek laiko tikrintu ta lentele ir radus dar neperduotu pakeitimu atidavinetu e-shop webservisui juos - jeigu atidavimas buvo sekmingas ir gaunamas is e-shop puseje esancio webserviso statusas kad jis priimtas, si tarnyba atitinkama pakeitimo irasa pazymi kaip perduota ir daugiau jo nebando perduoti >>>>> >>>>> * Tokiu budu nereikia perdavineti labai daug informacijos pastoviai o tik pakitimus - kuo dazniau ja keiciamasi tuo maziau jos susikaupia ir tuo maziau jauciasi sinchronizacijos darbas; >>>>> >>>>> * Taip pat imanoma padaryti, kad sandelys pasiiminetu uzsakymus, pvz vysktant kreipimuisi jis atiduoda uzsakymus ir gauna patvirtinimo kad sandelio likucio pakeitimas priimtas statusa bei, tuo paciu nauju uzsakymu skaiciu, o tada butu kazkokia kita webserviso funkcija is kurios butu galima paimt uzsakymus. >>>>> >>>>> >>>>> p.s. Statant papildoma tarnyba nebutu laginamas esminis sandelio darbas, kad sandelyje atlikus pakeitima nevyktu laukimas kol ji priims eshopas o tik pazymimas pakeitimas, o jau tarnyba vargtu su timeout'ais jei e-shop webservice down. >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> ### 2.2 Webservisas sandelio puseje - E-Shopas imineja likucius. Siuo atveju viskas vyksta atbulai >>>>> >>>>> 2.2.1 Sandelio puseje statomas webservisas prieinamas per interneta ir dirbantis su sandelio duomenu baze >>>>> >>>>> 2.2.2 E-Shope realizuojamas funkcionalumas kuris prireikus likuciu juos pasiimineja is webserviso ir aisku taip pat gali atidavineti uzsakymus ar dar kazkokia kita informacija. >>>>> >>>>> >>>>> ps. Tada aktyvi puse tampa e-shop, nes ji pastoviai kreipsis i sandelio webservisa ir jei nedarant jokios sinchronizavimo tarnybos tai per likuciu paemimus gali suletet viso saito darbas, nes atejus useriui kreipiamasi bus i kazkur internete esanty sandelio webservisa, ten bus imama sandelyje informacija, tada siunciama atgal i webservisa, gerai jei tai bus daroma daznai tai bus maziau duomenu ir greiciau viskas suveiks, bet jei retai tai tai gali pasiekt ir http timeout. >>>>> >>>>> Jeigu e-shop puseje statyt papildoma tarnyba kuri pvz kas minute tikrina pakeitimus ar nuimineja kazkoki tai sandelio statusa, pvz tik skaicius kiek vyko pakeitimu ir pan... tai tada pats e-shopas nebus kaip aktyvi puse ir dirbs net neveikiant sandeliui ar esant jam offline, o e-shop puseje esanti sinchronizavimo tarnyba vargs su visais sandelio timeoutais ir buvimais jo offline. >>>>> >>>>> >>>>> >>>>> P.P.S >>>>> >>>>> Tam kad nuiminet sandelio pakeitimus ir jeigu negalima modifikuot sandelio softo - galima naudot kad ir trigerius, kad nereiketu skenuot visos lentos ar keliu kur yra likuciai jei ten duomenu daug, bet kuriuo atveju turi suktis paktimu surinkimo tarnyba kad lenetint web requestu, kad kai jis vyksta tik tada pradet ziuret ar yra likuciu, o jau turet paruostus duomenis. >>>>> >>>>> Tada kazkurioje puseje tures buti vistiek web tarnyba kad paimt eitu ar atiduot likucius. >>>>> >>>>> P.P.P.S - Duomenu apsikeitimo technologijose visada labiau pazeidziama aktyvi puse, jei e-shop aktyvi puse, tai nuimti si nestabiluma galima su pamineta papildoma sinchronizavimo tarnyba. Bet kuriuo atveju internetas kartais ir dingsta, ar prarandamas rysys su konkrecia salimi kai koks ekskavatorius kasdamas koki kabeli nutraukia ir t.t.... >>>>> >>>>> >>>>> Duomenu apskeitimai viena is sriciu su kuria teke nemazai susidurt :) Siaip gerai nezinau visu smulkmenu tai cia kaip sakau tik pasvajojimas. >>>>> >>>>> -------- >>>>> >>>>> Freelancer Developer >>>>> http://www.lythum.lt >>>>> >>>> >>>> >>>> -- >>>> ... >> >> >> -- >> ... -- ....