PHP ir MySQL programavimas, SQL užklausos, duomenų bazės, PHP scriptai, pagalba, diskusijos, pamokos ir straipsniai.
You are not logged in. Please login or register.
PHP ir MySQL → Posts by Ajaks
Problema ta kad tu nesupranti tos vietos.
Kad ta vieta suprasti tau reikia zinoti kaip php kodas veikia toje vietoje.
Vienintelis kelias tai pasiekti - ismokti php kodo veikimo principus. Ismokti turi tu pats ir niekas kitas tau nepades. Mokintis reikia pradeti nuo geros knygos. Jeigu pats negali surasti geru knygu, klausk ir gausi patarima kur kokia pirkti.
Ar yra koks paprastas budas nehakinant kad po formos submito refreshinus puslapi nedarytu posto pakartotinai? Ir gal zinote koks? :)
Jeigu kalba eina apie konkretu pavyzdi, tai $rezultatas kintamasis yra tas pats ir vienoje uzklausoje ir kitoje uzklausoje, todel uztenka atlaisvinti atminti tik pacioje pabaigoje ir nebutina to daryti po kiekvienos uzklausos.
Ajaks, prie kokio didžiausio projekto esi dirbęs jeigu ne paslaptis? :)
Nes iš tavo post'ų matosi jog trūksta kompetencijos tokiems patarimams dalinti. :)
Ar tu nori 'pasimatuoti' ? Tu geriau nesimatuok, nes as paklausiu kiek tu uzdirbi dirbdamas prie savo 'dideliu projektu', ir baigsis visi matavimai labai greitai.
Tu pasiziurek, kiek tas 'builderis' uztrunka papildomai tikrindamas tipus ir kiek uztrunka to visiskai nedarydamas bet naudojant kabutes. Ir nereikes svaigti apie tiesas kurias sugalvojai is lempos.
Totali netiesa, normalūs query builderiai nuskaito lentelės stulpelius su tipais ir tinkamai viską sudėlioja. Duomenys apie stulpelius ir tipus - kešuojami.
'Normalus query builderiai'...ople, ura! Tai kam tada isviso vargti, jeigu yra 'normalus query builderiai' kurie viska padaro ir visiems viskas dzin. Neverta net sita tema kalbeti.
Ir kiek gi kainuoja nuimti kabutes? Iš karto rašant tvarkingai nereiks papildomai mokėti, kad kažkas papildomai optimizuotų kodą.
Požiūris yra esminis dalykas, jei px tai tikrai apie jokius facebook'us ar kokius kitus rimtus dalykus galima net negalvoti.
skaityk auksciau. Kaina - tai ne tik rasymas bet ir procesoriaus kaina.
Kalbam ne apie perdėtą optimizavimą. Kalbam apie tai kad iš karto rašyti teisingai ir kad niekam pažiūrėjus į kodą nekiltu kažkokių klausimų, kaip kad dabar. Aš ne šiaip sau čia paklausiau/parašiau, o todėl, kad ne kartą esu matęs ID laukus iš VARCHAR(255), kur realiai naudojamas INT'as. Ir čia nieko nuostabaus, gal ir pats kažkada senai taip dariau. šiuo atveju netgi ir svarbesnis punktas, kad kažkas ne taip kažką interpretuos ir papildomai gaiš laiką ten, kur nereikia.
Siuo atveju mes kalbam ne apie varchar 255 o apie tai kas daugiau kainuos: ar kabuciu nerasymas ar ju rasymas ir leisti sistemai atsirinkti.
Yra du variantai: saitas mazas ir viskas daroma rankiniu budu arba saitas didelis ir sql generuojama automatiskai. Jeigu saitas mazas, tai gali rasyti, gali nerasyti tu kabuciu, greiciui realios itakos tai netures. Jeigu saitas didelis, ir daromos automatines sql query, tada turi papildomai rasyti patikrinima kokiam nors php lygyje kad suzinoti koks tipas ir tada arba jas deti arba nedeti. Visas tas patikrinimas ir salygu sukurimas kainuos daugiau negu leisti kokiam mysql lygyje sistemai paciai prisitaikyti.
Ajaks, nežinau ką čia iš tikro nori išvedžioti. Skirtingo ilgio teksto išvedimas ir STRING konvertavimas į INT nėra tolygūs dalykai. Aš nesakau, kad konversija yra nežmoniškai brangi. Bet jeigu gali neišvedinėti bereikalingo teksto - neišvedinėk. Jeigu gali išvengti bereikalingos operacijos - išvenk.
SQL užklausos yra linkusios būti vykdomos šimtus, tūkstančius ir milijonus kartų. Projektuose skirtingų užklausų dažniausiai yra nuo kelių iki keliasdešimt kiekvieno puslapio užkrovimo metu. Papasakok facebook ar google inžinieriams, kur sutaupyti tūkstantąją serverio apkrovimo dalį vienos užklausos vykdymo metu ir jie tau tikrai pasakys daugiau negu ačiū (-;
Dėl bendro sąnaudų-rezultato skaičiavimo aš iš principo sutinku, bet šiuo atveju tas negalioja, nes sąnaudos ar parašyti 1 ar '1' yra vienodos.
čia tos kabutės yra tik šiaip, bendras pastebėjimas prie kur kas svarbesnių dalykų.
Jeigu nezinai tai paaiskinsiu: tavo pasakyme "Jeigu gali išvengti bereikalingos operacijos - išvenk" truksta vieno dalyko: Kiek tai kainuos. Esminio dalyko kurio daugelis nesuvokia ir uzsisuka i nezmoniska optimizavima, nezinia kiek laiko ir uz nezinia kokius pinigus. Uzsisuka tiek kad eda babkes ir neduoda atitinkamos naudos.
Kitaip tariant nereikia uzsiimti perdetu optimizavimu. Ir mes apie feisbukus nekalbam nes nei tau nei man tas negresia.
Tai galima parasyti vienu zodziu maziau teksto output'e ir bus tas pats procesoriaus energijos sutaupymas.... :)
Teisingas poziuris yra sanaudos in -> rezultatas out. Ir kiek uz sanaudas gauni rezultato. Jeigu gauni labai mazai, neverta gaisti laiko apkraunant automatini SQL generavima ir papildomu if'u kisima (:)
2) verti mysql serverį papildomai atlikti konversiją iš STRING tipo į INT tipą;
Ir tai reikalauja net 0.001% serverio pajegumo :)
Arba, kaip sako hebra is dideliu saitu, viska reikia nafig keshinti :) T.y. dazniausiai naudojamus filtrus ir t.t.
drs> tau reikia info del greicio ar apskritai del filtravimo? Nes filtrai tai WHERE XXX = "laukelis_xxx' AND YYY = 'laukelis_yyy'
tai is formos per POST partraukus duomenis irasai bet kaip is sio pavyzdzio i forma tarkim tuos tris paveikslelius istatyti ..
Taigi md5 imete linka.
i forma istatyti su situo jquery. O poto tau reikia is formos irasyti i duomenu baze. Cia kitas procesas apie kuri paieskok informacijos. Rasi.
Kazka tu cia ne taip darai. Pradek nuo instrukciju skaitymo.
Nerasyk zodziu o paduok kintamaji is masyvo tiesiai i preg_replace.
Tai tame ir esme, kad nelabai turiu teisiu prieiti prie tos formos :)
Meginau as toki varianta, kazkas negerai buvo - bet pameginsiu tuojaus, gal perkaitus galva buvo; (P.s) pas tave pavizdyje be "galo tikrinimo"
Dabar irgi pasirasiau paprasta toki: reg_replace("'(vienas|du|trys....")$'", '', $x); irgi nevisai gerai veikia nesuprantu del ko
tai pasiziurek kaip veikia preg_replace syntakse. Gal reikia kazka escapinti. Beto pas tave ne tarpai o bruksniai kazkokie. Kodel.
Na gali tuomet varyti preg_replace per cikla su kiekvienu masyvo nariu ir tikrink ta pati stringa ir jeigu randa, istrini norima zodi ar zodziu jungini. Arba tikrink string'o dali.
foreach($uzdraustas_masyvas as $uzdraustas_zodis)
{
preg_replace ($uzdraustas_zodis, '', $sexy_stringas);
}Nors klausimas kaip tie useriai viska iveda, gal ivedimo formoje galima padaryti pakeitimus.
EDIT: pataisiau, turejo buti preg_replace.
Papasakok platesni vaizdeli, ka nori padaryti?
Is pirmo posto matosi, kad tarp zodziu yra tarpai, bet veliau tarpu nebelieka? Ar atsiranda dvigubi zodziai?
Jeigu taip, padaryk dvigubus zodzius laikinai viengubus (su kokiu nors bruksneliu), tol kol daromos operacijos. Poto bruksneli panaikink.
Is kur zinai kad nebuvo?
Nu nezinau, buna kad kazkas sugenda. O poto tai yra sutvarkoma. O kas cia naujo siame pasaulyje? Kas dirba be gedimu?
PHP ir MySQL → Posts by Ajaks
Powered by PunBB, supported by Informer Technologies, Inc.