Java

int datu tipam tu neraksti projektu, savukārt object datu tipam raksti pats savu projektu - es domāju, ka saprati.

P.S.

Var jau teikt arī nevis "projekts", bet gan "skice"

Neiet runa par klasi kā datu tipu, kas protams tā ir, bet gan pēc būtības - kad skaties uz kodu un atšķirības no int datu tipa ir jūtamas.

Precīza skice - paredzēta realizēšanai un ekspluatācijai.

Nu pag, klase ir projekts, no kā veidot objektus :P

Diskusija atdalīta no http://php.lv/f/index.php?s=&showtopic...ost&p=95822

Skaties uz klasi kā uz objektu "projektu" - tā ietekmēs objektus un to darbību vistiešākajā veidā plus vēl tas, ka projektam jābūt "kārtīgam" - visām līnijām jābūt novilktām tur kur vajag ;)

Es tak teicu, ka tā klase izskatās pretīgi jau uzmetot acis vien. Nu uzreiz skaidrs, ka tur daudz kas nav riktīgi, pat īpaši netērējot darba laiku analīzei :P

Priekš kam tā bezjēdzīgā klase ir vajadzīga tādai funkcijai kā taimera palaišana un nolasīšana? Pirmkārt tā klase izskatās pretīgi, otrkārt - tā noteikti strādās lēnāk nekā izsaucot pa tiešo php funkciju un miers.

....... COUNT(t1.user_id) as uid_count1, COUNT(t2.user_id) as uid_count2 FROM tabula1 t1, tabula2 t2 WHERE ........

Kad sākšu atkal nopietnāk pievērsties php, izmēģināšu ar kaut kādus performances testus...

Tākā JAVA to visdrīzāk nezin, jo nav atbildējis, tad pateikšu kā var dabūt vairākus SELECTU datus no viena CALL kverija:

copy/paste from php manual - nu tu esi zeks! Nav laika rakstīt piemērus, man darbs, es pateicu ideju un vsjo.

Piemēram, CALL GENERATE_MENU(@active_item, @menu_name);

Nu pag, viņš tur uzrakstījis 3 dažādus nesaistītus querijus.

Es tak neteicu, ka ir jābūt vienai storētai procedūrai "CALL GENERATE_ALL_MY_SITE_DATA();", bet gan ka saistītos querijus var izpildīt storētā procedūrā. Views izmantot kā palīglīdzekli.

Ja Tev nav humorizjūtas par e-vidi, tu neesi pa īstam tajā iekšā ;)

martins256 - esi dzirdējis par tādu lietu kā Views?

Kā tieši, Java, tu plāno apvienot vienā rezultātā dažāda platuma, garuma sql rezultātus?

Par daudzdimensiju masīviem esi dzirdējis?

bubu, kāpēc tad tik ilgi diskutēt, ja mana sākotnējā doma tāda arī bija?

Es, protams, nesaku, ka nevajag lietot storētās procedūras. Tās vajag lietot, lai atdalītu SQL kverijus no php koda. Taču, tās itin neko labāku optimizācijas ziņā īpaši nedos.

Un es arī teicu, ka neesmu pārliecināts vai tas dos ko ātrdarbības ziņā... Pieņemu, ka uz nelielu projektu nekādas dižās atšķirības nebūs.

Maciities, maciities un velreiz maciities.

PALDIES!

Teica Vasīlijs no Ļeņigradas.

Nu var arī iekešot, bet nu ja ir kaut kādi starpkveriji?

Datubāzi vajag optimizēt, bet, ja tā atbilst vismaz pirmajām 3 normālformām pilnībā, bieži vien sanāk daudz relācijas! :D

Ja kādu interesē, tad ZendFramework 1.7 iznākšanas datums ir 16.11.2008! Tātad vairs tikai pāris nedēļas.

Man jau ir nopirkti šampanieši un pirotehnika grandiozam salūtam, kas tiks palaists tieši uz pirmo ZendFramework 1.7 downloada MacBookā 16. novembrī Krastmalā!

E? kā tas ir jāsaprot?

Tā, ka tu MySQL galā izdari lielu daļu darba un db pieprasījumus iekš vienas procedūras, ko izsauc php ar vienu pieprasījumu mysql_query("CALL MY_PROC(tram1,taram2,param3);",$db_link); un izmanto atgrieztos datus nekā veic atkārtotus querijus no php gala.

Ja gribi optimizēt queriju, varbūt uztaisi vienu procedūru, kas MySQL galā uztaisīs ciklu un atgriezīs iekš php vienkārši masīvu, ko izmantot, tev nebūs jāvēršas pie db atkārtoti... Bet neesmu mēģinājis, neesmu drošs, vai tas optimizēs ātrumu.

Otrs variants - ej cauri kodam, skaties, kur notiek pilnīgi liekas lietas.

BTW, ko gribi optimizēt - servera gala izpildi vai klienta gala?

Ar tabulu layotiem ir mazāka sāpe par starppārlūku savietojamību.

Tiesa, labot ar tabulām veidotu layoutu ir neērtāk un arī nekāda semantika nesanāk

Ja neprot taisīt layoutus, tad vismazākā sāpe ir taisīt html4 bez kādas validācijas, izmantojot FrontPage vai kādu nu bērnu tūli tur izmanto tādi cil®vji...

Esmu pats taisījis gan ar tabulām layoutu, gan bez un tā, ka viss validējas arī XHTML 1.0 Strict un es varu pateikt atklāti:

Bez tabulām veidojot bieži vien ir jātaisa css haki, bet - ir jāiemācās visu layoutu veidot tā lai tie haki ir jālieto minimāli pat uz portāla layoutu! Un tā ka viss validējas un korekti rādās uz 6 dažādiem populārakajiem pārlūkiem! Un to var dabūt gatavu, vajag tikai papūlēties un iemācīties. Nezināšana vai slinkums nav attaisnojums nekad, skaidrs, ka veidojot visu layoutu uz tabulām, tas būs sarežģītāks un līdz ar to arī sliktāk manipulējams DOM. Veidojot layoutu ir jādomā par tiekšanos uz ne tikai tīru un valīdu kodu, bet arī optimālu DOM!!!

Kāda starpība - strādā pie tā, kas patīk! Man piemēram, nav nekas pret datubāzēm, ir interesanti - bet lai es to vien darītu katru dienu, kaut vai par lielāku algu - NĒ, paldies! Jā, pāris dienas nedēļā pārmaiņas pēc ar datubāzēm strādā pietiekami nopietnā līmenī man patīk!

Man tieši patīk tas, ka webā ir daudz jāmācās...

Nepatīk tas, ka diemžēl webā sarodas baigi daudz visādu jefiņu, kas tēlo programmētājus, jo galu galā html, css un php pamatlietas ir iemācīties easy un tam ir maz sakars ar programmēšanu...

Webā nemaksā maz, ir viena atšķirība gan - tur lai daudz prasītu, vajag spēt arī nopietnā līmenī kaut ko piedāvāt pretim! Tādā stipri nopietnā līmenī...

Weba nopietnības līmenis neatšķiras būtiski no C++ , Java vai .NET nopietnības līmeņa, ja runājam prastā valodā, tikai ja tiešām iet runa par NOPIETNU web-programmēšanas līmeni - kad var ne tikai uztaisīt klases uz php, bet arī interfeisus, sistēmas, prasmīgas savietošanas ar datubāzēm, webservisiem, kvalitatīva skriptēšana (JavaScript utt.) - tas jau ir pietiekami nopietns līmenis, kurā iekšā ir arī visas algoritmiskās domāšanas.

Var arī taisīt desktop aplikācijas, ja tā interesantāk ir...

Vari taisīt Squad kaut vai kosmisko satelītu kontroles sistēmas, kas tev liedz?

Bet beigu beigās paliekam pie tā, kas ir vairāk pieprasīts un ko var apgūt pašmācības ceļā, jo ir arī jomas (piemēram, ķirurgs), kur jāmācās sistemātiski pēc noteiktiem plāniem gadiem.

Webā pamatus var apgūt un tālāko apgūt jau diezgan nesistemātiski... Patiesībā - gandrīz visā programmēšanā tā - galvenais apgūsti kārtīgi pamatus un lietai vajadzētu aiziet, ja vien domā līdzi un neesi Ābrams Artūrs Cirvis.

Neredzu kodu diemžēl, bet ja topika autors pats nav ievērojis, tad pateikšu priekšā:

NĒ! Tieši uz firefox tu uzraksti tīru css un parasti viss arī strādā kā vajag (nepietiekamas zināšanas css nav attaisnojums), bet uz IE ļoti bieži jālieto visādi css un dažreiz pat javascript haki!

Vēlreiz atkārtoju - es uzskatu, ka nav jālieto tabulas, kur tas loģiski nav nepieciešams.

Ja tev ir tabula, tad, protams, jālieto <table>. Kurā vietā esmu noliedzis faktu, ka tabulas drīkst pielietot vispārīgi?

Bet es nedomāju, ka viss layouts jātaisa table iekš table iekš table utt. Tas daudz par daudz palielina html izmēru, jo visi tie <tr> un <td> summējas. Pie tam - ar javascript ir ērtāk darboties ar mazāk elementiem, kam katram savs id vai class.