tai rinka ir sureguliuoja, kas nori kokybiskai ir renkasi kokybiskai, o kas nori pigiai, renkasi pigiai ir paskui kokybiskai. Jei DB reorganizuojamos tai dazniausiai tam buna priezastis ir labai daznai tai visiskai nesusije su techniniais ribojimais. Jei reikia, kad duomenu negautu koks prasalaitis "hakeris", tai naudosiu viena buda, jei reikia, kad duomenys isliktu bet kokia kaina ir prieinami kita, taip, kad kas is pirmo zvilgsnio atrodo kvaila, po kurio laiko gali pasirodyti genialu ;) bet zinoma tobulinant produkta visada gali atsirasti tokiu, kurie pasakys, kad "iki siol dirbot neteisingai, dabar viska istrinam ir darom taip". Tam ir reikalingi projektu vadovai, kad po tokiu pasakymu, tai nepavirstu darbais.. On 02/09/2011 03:17 PM, If wrote: > Viska lemia rinka. Reguliuojamoje rinkoje viena konkurencija, > nereguliuojamoje kita. > Jei Lt taptu konkurentabili nereguliuojama rinka, daugelis uzsakovu islektu > momentaliai i ora, > kartu su tokiomis IT sistemomis ant kuriu jie dabar sukasi ir visais ju > "bendrautojais". > Pasakiau aiskiai, nuo briuselio link pumpenu, dazniausiai reorganizuojamos > pacios DB, kai > programinio kodo branduolis, daznai centralizuotas, tokiu atveju kalbeti nei > apie duomenu > strukturas, nei apie ju rysius nei apie elmentariu OOP ar duomenu sauguma, > nera prasmes. > O kas leicia kvalifikacija, tai buroku respublikoje ji paprastai giminystes > rysiais pagrista, > ir neduok dieve, kai tenka tokiu "kvalifikuotmeisteriu" idejas kartais > realizuoti :) > > "Dainius"<dainius@something.com> wrote in message > news:iiu2gl$49e$1@trimpas.omnitel.net... >> bendrauti su uzsakovais turi kvalifikuoti zmones ir zinantys kaip >> bendraudi, o ne tech personalas. Ne daug surasi programuotoju galinciu >> tinkamai tai atlikti, deja.. >> Normaliai sudelioti rysiai informacijos nenaikina, nei keliaujant i >> Briuselio i Pumpenus, nei is Pumpenu i Briuseli, kad ir per Zimbabve. >> Beda, kad gaugelis "web" programuotoju nesupranta, kas tie rysiai, bet cia >> ne DB problemos. >> Duomenu isskirstymas turi savu privalumu, nors kai kuriems specialistams >> tas gali ir pasirodyti keista.. bet kaip tai susije su OOP vis tiek >> nesupratau. Matyt sunki vaikyste buvo pas kazka. >> >> Sunku vis tik, kai zmones sarkazmo nemato ;) >> >> On 02/09/2011 01:28 PM, If wrote: >>> Kol kas nors, po kurio laiko negauna si nuostabu "palikima", bandant >>> atkapstyti galus, kai uzsakovas rodo vaizdeli vienam monitoriaus ekrane, >>> i >>> kita kitame ir sakoma, kad jam reikia TIK..... O dazniausiai tas TIK..... >>> tai jo TIK.... suvokimas kiek reikalauja pastangu atgal tokias "avis" >>> suvarineti, ypac kai rysiai tarp ju tokiu nuostabiu formatu ir daznai, >>> kaip >>> as sakau DB reorganizacijos budu, slenkantis nuo Briuselio link Pumpenu >>> kaimo, rysius nustant to paties Briuselio biurokratiniais >>> plunksnakociais. >>> Idomius laikus isgyvena siaip Duombaziu strukturos, bazes >>> reorganizuojamos, >>> softas spaudziamas i vienas rankas. :) >>> O paskui ir griuna visokie wikileks sou, kad ir ne marijos zemeje. Pagal >>> viska, kaip tatutos isrinktieji, konmentavo si procesa, kad reikia DB dar >>> labiau reorganizuoti, tipo kaip ju santaupas, kuo labiau isskirstysi, tuo >>> saugiau, idomu koks zuikutis jiems ta minti pasnibzdejo, ipatingai >>> turinti >>> "glaudu" sarisi su OOP ir "duomenu saugumu" :) Tai kad pagal viska sie >>> reorganizacijos metodai, ateiti gali buti dar labiau paklausus ir verslus >>> :) >>> "zZz"<zZz@zirzilia.lt> wrote in message >>> news:iisger$3mc$1@trimpas.omnitel.net... >>>> galima. kadaise jà pavadinom integer ;) >>>> >>>> "Dainius" wrote in message news:iiro96$5i5$1@trimpas.omnitel.net... >>>> >>>> o dar galima sukurti atskira duombaze, kur sukisam visas galimas XXXX >>>> kombinacijas sukuriam 3 indeksus ir leidziam naudoti... >>>> >>>> >>>> On 02/08/2011 02:48 PM, Jornada Del Muerto wrote: >>>>> O kudel gi ne, siaip gal dzipa siulyciau, tankas per daug demesio >>>>> sukeltu, nors ir domiuosi ginklais :) esme tik kad kaip ir if sake, >>>>> nepasakyta koks SQL, o LIKE bus praktiskai visur, kaip sakant jei >>>>> vyksta >>>>> stringo karpymas jis darosi kitaip skirtinguose sql... >>>>> >>>>> Kita vertus galima aisku cia teoriju prigalvot, net >>>>> optimizuojanciu >>>>> paieska, pvz. >>>>> >>>>> 1. Gaunam stringa XXXX-XXXX-XXXX; >>>>> 2. Irasome i duomenu lenta; >>>>> 3. Tada splitinam per '-' simboli i atskirus XXXX elementus, juos >>>>> itraukiam i sekancia lenta jei neegzistuoja dar jie joje, jeigu >>>>> egzistuoja einame prie 4 punkto, jeigu ne itraukiame ir einame prie 4 >>>>> punkto: >>>>> >>>>> TABLE search_values ( value_id PK, value<unique index> ) >>>>> >>>>> 4. Fiksuojame search_refs lentoje atitinkamu splitintu XXXX >>>>> reiksmiu >>>>> value_id ir duomenu lentos iraso id. >>>>> >>>>> TABLE search_refs ( id PK, value_id<index>, ref_id - duomenu >>>>> lentos >>>>> iraso id aka duomenu_lentos_id ) >>>>> >>>>> 5. Paieska tampa trivialia: >>>>> >>>>> SELECT >>>>> d.* >>>>> FROM >>>>> search_values sv >>>>> INNER JOIN >>>>> search_refs sr On sr.value_id = sv.value_id >>>>> INNER JOIN >>>>> duomenu_lenta d On d.duomenu_lentos_id = sr.ref_id >>>>> WHERE >>>>> sv.value = 'XXXX' >>>>> >>>>> Vualia ;) 2 lentom daugiau, taciau elementarus selectas viska graziai >>>>> istraukia ;) toks principas naudojamas paiesku indeksavimams. >>>>> >>>>> >>>>> Sekmes! >>>>> >>>>> Freelancer Developer >>>>> www.lythum.lt - new design / tiesa dariau pats, o neesu designeriu :) >>>> >>> >>> >> > >