Aleksejs

Ir arī vairāki citi drošības modeļi: http://en.wikipedia.org/wiki/Category:Comp...security_models Augstāk aprakstītais pēc būtības ir: vienkāršots ACL (tāds pats kādu izmanto unix failu sistēmā). Neviens neliedz izmantot arī kādu citu. ;)

WHERE (aid = 94 AND lauka_mid = 12) OR (aid = 94 AND lauka_mid = 13) jeb WHERE aid = 94 AND (lauka_mid = 12 OR lauka_mid = 13)

Kurām rindiņām jābūt atlasītām no tevis minētās tabulas?

Lai mēs kautko gribētu pamainīt, Tev mūs ir jāieintriģē izlasīt to koda gabalu, jāparāda kas tieši un kurā vietā nedarbojas, jāparāda, ka vispār pats saproti, ko raksti un ka spēsi novērtēt piedāvātos risinājumus. Pagaidām, es personīgi, neko aizraujošu nesaredzu. Varbūt kāds saredzēs, bet visticamāk, ka pie šāda problēmas formulējuma, nē.

Varbūt uzlabo savas zināšanas izlasot, piemēram šo dokumentu: http://lv.php.net/manual/en/langref.php

Nu, kā vēlies...

Lūdzu vēlreiz noformulē savu jautājumu.

Varbūt pamēģini ASC ;)

Un pēc būtības... vai nav tā, ka pietiek ar vienu SQLu: UPDATE tabula SET lauks = 0 WHERE lauks = 1 Uj, jau sākumā tika pateikts, sorry. :)

Pirmajā SQLā pietiek tikai ar atgrieztiem id, manuprāt. Tātad: SELECT id FROM tabula WHERE lauks = 1

LTK Ultra DSL Rīga - strādā; Telecentrs Rīga - strādā; ;) tad DNSā bija tā vaina?

UNION atbalsta gan ORDER BY, bet ņemot vērā, ka pēdējos pāris mēnešus ir nācies daudz strādāt pie SQL pieprasījumu optimizācijas, varu pateikt, ka UNIONs ar ORDER BY būs (using temorary, using filesort), ja to mēģināsi papētīt ar EXPLAIN (MySQLā, protams ;) ). Jā, protams, tās jau ir detaļas un varbūt, ka nav būtiskas šajā gadījumā, taču no optimizācijas viedokļa - tas ir slikts pieprasījums. ;) ja tas izpildās reizi mēnesī, tad, protams, nav nekāda vaina, taču, ja reizi minūtē, tad jau jāsāk aizdomāties ;) Un par normālformām runājot, ne vienmēr normālformas ir jāieto. Klasisks piemērs - glabāt komentāru skaitu pie raksta, nevis katru reizi izsaukt SELECT COUNT(...) pieprasījumu. :) Ja strikti vadītos pēc normālformām, tad komentāru skaits ir lieka informācija, taču dublējot šo lieko informāciju mēs iegūstam būtisku ātrdarbības pieaugumu ;) Bet, protams, katrs gadījums jāizvērtē atsevišķi.

andrisp, ir arī trūkumi sadalīšanai. Piemēram, ja gribam atlasīt visus lietotāja l komentārus visās sadaļās, vaicājums izskatās aptuveni šādi: select * from sad1_komentari where lietotaja_id = l union select * from sad2_komentari where lietotaja_id = l union ...//tā katrai sadaļai Ja vēl galarezultāts ir jāsasortē, tad (manuprāt) datubāzei būs jāizmanto temporary tabula, lai parādītu rezultātu katru reizi. Un vēl, pievienojot klāt jaunu sadaļu, būs jāpapildina vaicājums. Bet, protams, jāskatās pēc situācijas. ;)

Nu, jā... Te nu mēs redzam atšķirību starp to, ko no foruma sagaida viens un ko sagaida citi. Civēki, kas šeit apgrozās kaut arī palīdz par velti problēmu risināšanā, tomēr sagaida arī dažas lietas: 1) Lai problēma/jautājums būtu interesanta; 2) Lai būtu redzams, ka jautātājs ir motivēts aktīvi piedalīties risinājuma atrašanā. Ja kāda no šīm lietām nav, tad... oh well... ;)

Izlasi šo te: http://hackmysql.com/optimize

Ok, neprecīzi izteicos: bubu, kādas ir tavas pārdomas par iemesliem, kādēļ esošajos trakeros ir caurumi? ;)

Nu... AJAX trasēšana ir diezgan ķēpīga lieta... Lai mēs varētu palīdzēt noskaidrotu problēmu, tomēr laikam vajadzēs vairāk detalizētākas info. Ja lieto firefox, uzliec Firebug spraudni. Vēl ļoti noder proxomitron. Paskaties, ko reāli Tavs skripts sūta un ko tieši serveris atbild ;)

Šis ir viens no labākaiem Latvijā/latviešu valodā esošajiem forumiem. Uzskatu, ka foruma administrācija ļoti labi veic viņiem deleģētos pienākumus.

bubu, un kāpēc, kā Tu domā, tajos esošajos trakeros vispār ir tie caurumi? Domā, ka tos rakstījuši cilvēki, kas neko nesaprot no šīm lietām? ;) Jā, noliekot koda drošību kā vienu no projekta pamatuzdevumiem, var uztaisīt diezgan pārdomātu no drošības viedokļa produktu, taču tas negarantē, ka tomēr kādā (šobrīd iespējams nezināmā) veidā aizsardzību nav iespējams apiet.

"Security through obscurity" ir ļoti slidena taciņa. ;) Varbūt, ka šajā konrētajā gadījumā arī būtu ok izmantot šādu drošības stratēģiju, bet padomā, kas notiks, ja tomēr kāds atradīs caurumu Tavā kodā... Tām sourcēm, kuras Tu tik dikti lamā apakšā ir vesels bars ar kodētājiem, kas ļoti labi zin, kas un kā un kāpēc tajās notiek un kļūdas atklāšanas gadījumā ir spējīgi operatīvi uztaisīt ielāpu, kas novērš atklāto kļūdu. Kas būs Tavā gadījumā? Vai nebūs tā, ka darbs būs vispār paralizēts? ;) Jā, ja Tu spēsi izveidot spēcīgu komandu no cilvēkiem, kas tiešām sajēdz šīs lietas un kuriem ir pietiekami daudz resursu (lasi laika/naudas), lai varētu aktīvi piedalīties, tad vari domāt.

Atkārtošana - zināšanu māte (-; Bez tam līdz ar jaunpienācēju zināšanu celšanos, ceļās arī risināmo problēmu sarežģītība un tiek risinātas tādas problēmas, kuras par triviālām vairs nenosauksi.

Es jau otro gadu kā izstrādes platformu izmantoju Linux. Ja vajag notestēt, kā izskatās uz IE, tad pieslēdzos caur terminālo serveri windows kastei.

Ar InnoDB nebūs tik vienkārši (-;

Paulinj, a kas ir drošība? Principā arī serverim elektrība nav bezmaksas un arī interneta pieslēgums parasti tāds nemēdz būt...

Bet vai pats bubu to grib? (-;