bubu

Nevis ACSI, bet ANSI (American National Standart Institute, vai kautkā tā līdzīgi). Un šis kodējums NEPAREDZ krievu burtu attēlošanu, bet tikai angļu!

Kas ir ACSI kodējums, kurš uztur krievu un angļu valodu, bet latviešu nē?

Nu tak elementāra rekursija: Tabulas struktūra (table): id name parent_id --------------------------------- 1 virs1 0 2 virs2 0 3 apaksh1.1 1 4 apaksh1.2 1 PHP skripts: function display($parent) { $res = mysql_query("SELECT * FROM table WHERE parent_id = $parent"); while ($row = mysql_fetch_row($res)) { echo $row[1]. "\n"; display($row[2]); } mysql_free_result($res); } display(0); Kaklz: rekursija nav slikta, ja to izmanto pareizā vietā pareiziem mērķiem. Piemēram, tādam kā šis. Rekursiju vajag mācēt pareizi izmantot, tajā ir liels spēks! ;)

Ģeniāls problēmas izklāsts. Nekā nevar saprast ;)

A kurš prasīja maz....mazbērnu skaitu? Manuprāt jau vajadzēja tikai vienā līmenī bērnu skaitu.

man ir: $ieprieksheejais_menesis = -1; while (veel_ir_meeneshi) { if ($iepriekshejais_menesis != $tagad_menesis) a tev ir: while (veel_ir_meeneshi) { $ieprieksheejais_menesis = -1; if ($iepriekshejais_menesis != $tagad_menesis)

tas tāpēc ka tu neieveeroji manu pseidokodu: (1) if ($iepriekshejais_menesis != $tagad_menesis) { echo "Tagad ir mēnesis: " . $tagad_menesis; $iepriekshejais_menesis = $tagad_menesis; } (2) // drukaajam ierakstu (ar mēnesi $tagad_menesis) visdrīzāk tu esi apmainījis vietām (1) un (2)

Nu ja, pareizi! Un lai dabūtu visu apakšgaleriju skaitu x vietā 0: select count(*) from galleries where gallery_id = 0

$ieprieksheejais_menesis = -1; while (veel_ir_meeneshi) { if ($iepriekshejais_menesis != $tagad_menesis) { echo "Tagad ir mēnesis: " . $tagad_menesis; $iepriekshejais_menesis = $tagad_menesis; } // drukaajam ierakstu (ar mēnesi $tagad_menesis) // ielasam naakamo ierakstu }

Kā tev izpaudīsies tās apakšgalerijas, kā tu tās glabāsi DB? Ja norādot virsgalerijas ID, tad to varēs mierīgi izdarīt.

galleries un images laukus čista nevajag, tos var dabuut ar COUNT(*)

Array pēc būtības php var izmantot divos veidos. Viens ir tāds, kā jebkurā citā programmēšanas valodā. Parasts masīvs ar indeksiem pēc kārtas. Šim pielietojot array_reverse nevajadzētu būt nekādu problēmu. Jo, ja jau masīva elementi ir pēc kārtas, tad tos apgriezst otrādi nevajadzētu būt nekādu neskaidrību. Bet iekš php array var izmantot kā datu struktūru, kuru sauc par dictionary. Tas ir, kad kautkāds strings saistītts ar citu. Tas pierakstās teiši šādā veidā: $masivs['kas'] = 'ar ko saistīts'. Un šajā gadījumā, piemēram, es īpaši neredzu jēgu darīt to array_reverse (vai arī array_push) jo šai datu struktūrai galīgi nav nekāda šķirba kādā kārtība iekšēji tā satur stringus, tb kurš ir sākumā, kurš beigās, jo adresācija notiek vai no pārlasot visus elementus, vai meklējot kādu konkrētu pēc atslēgas/vērtības. Varbūt tev vajag padomāt, ko tad īsti gribi panākt ar savu skriptu, ja izmanto abus veidus reizē.

Pilnībā piekrītu DimanC teiktajam.

Nu jā, protams, ka var tā darīt, ja iepriekš jau zināmas kategorijas. A ja tās ir dinamiskas, tad tās arī jāglabā datubāzē un jāvel no ārā no tās.

Tev tak dīvains tas pirmais if nosacījums: Ja (neeksistē tāds fails VAI (eksistē tāds fails UN tas nav direktorijs)) tad { viedojam tādu direktoriju} Padomā, kas notiks, ja eksistēs tāds fails UN tas nav direktorijs!! Tad skripts mēģinās veidot direktoriju ar tādu nosaukumu, kāds jau eksistē!! Un vēl, vai tev ir tiesības veidot tur tos direktorijus? Pamēģini vienkārši palaist kautkādu šādu skriptu: mkdir(PICS_TOP_PATH.'JaunsDirektorijs'); un kas tad notiek?

Starp citu, neredzēju, ka formai būtu norādīts: form name="form_1" action="blabla.php" method="post" enctype="multipart/form-data"> enctype!!! tev pareizais? Jā un vēl, php manuāli, tak speicāla nodaļa, par failu uploadošanu: http://lv.php.net/manual/en/features.file-upload.php un par **vairāku** failu uploadošanu: http://lv.php.net/manual/en/features.file-...ad.multiple.php

Apmēram, tas pats par to funkciju, kas izvada. Vienīgi es biju domājis arī automatizēt virskategoriju izvadi, lai nav ar roku tās jāvada, t.b. glabāt arī datubāzē.

Var jau to uzrakstīt ar vienu selektu, apmēram tā: SELECT virs.name, zem.name FROM kategorija virs, kategorija zem WHERE virs.id = zem.virs_id GROUP BY virs.name ORDER by virs.name, zem.name bet tad protams, PHP skriptā ciklā vadot ārā nosaukumus jāapskata, kuriem virs.name ir vienāds, un ja atšķirās, tad veidot jaunu kategoriju. ķēpīgi. a otrs variants ir uzrakstīt funkciju, kas dotai kategorijai izvada apakškategorijas, un tad galvenajā programmā dabū virskategoriju nosaukumus un id (apmēram šādi: SELECT name, id FROM kategorija WHERE virs_id IS NULL ORDER BY name) . Tad ciklā tās vada ārā un katrai izsauc uzrakstīto funkciju, padodot tai virskategorijas id. Tā savukārt izselektē apakškategorijas (piemēram, SELECT name FROM kategorija WHERE virs_id = $id ORDER BY name). Un manuprāt šis variants ir prātīgāks.

Viens variants ir uztaisīt trīs laukus bildes tabulā: 800x600, 1024x768 un 1280x1024 izšķirtspējām. Vienkāršākais variants, bet ne fleksibls. Grūti būs kautko pēc tam uzlabot. Ja grib unviersālu, tad vajag jaunu tabulu, kurā ir ceļš uz bildi, bildes izmēra ID, vai tekstuāls apraksts un bildes ID, kurai tad īsti bildei no bilžu tabulas tas atbilst. Šo jau nu pats varēji izdomāt, nekā ūbersarežģīta te nava. Ja iet runa par albūmiem, tad protams, ka vajadzēs jaunu tabulu Albūms, kuram būs lauki ID un TEXT ar aprakstu, savukārt pie katras bildes, būs tā albūma ID, kuram pieder.

Kas nu kuram skaitās vieglāk. Vai nu apstrādāt ierakstus failā, vai arī labi pārzināt SQL un veidot pieprasījumus :)

Par ātrdarbību gan negribu piekrist. Man liekas tieši otrādi, ka MySQL ir lēnāks. Bet, lai to pierādītu, jāveic testi. Tā ka īsti precīzi neizinu. Un 4.1 versija MySQLam atļauj dažos gadījumos rakstīt šādus SELECTus. Un tāpat bieži vien tādus pieprasījumus var pārrakstīt, neizmantojot apakš-SELECTus.

Protams zināms, ka PostgreSQL ir jaudīgāks nekā MySQL, ar to ka uztur vairāk dažādas SQL iespējas: skatus, trigerus, procedūras, u.t.t. Bet vai mūsu latvijas parastam web-dizainerim tas viss vajadzīgs? Es domāju, ka ne. Tamdēļ arī visi pieturās pie MySQL, tā vienkāršuma ziņā (salīdzinājumā ar PostgreSQL). Ar to uzstādīšanu ir tiešām čakars. Uz tīra tikko svaigi instalēta Windows (vismaz uz XP mēģināts) šis uzstādās bez problēmām ar pirmo reizi. Bet pašam ir nācies to instalēt uz Windows2k, kurš pārinstalēts nav ticis apmēram gadu. Ņemšanās bija pamatīga, kamēr sapratu, kur tas suns aprakts. Protams, vēlāk vairs nebij nekādu problēmu.

Nav tas protams, nebūs tā vienmēr! Tas ļoti atkarīgs no datu lieluma/satura/veida!

Ar normālformu viss ir ok, bet veidojas tā sauktā arka, kad arējā atslēga var iet vai nu uz vienu entīti vai uz citu, kas bieži (ne vienmēr) vien negatīvi atsaucas uz ātrdarbību. Es ieteiktu tā kā jau teicu, TEXT lauks pie bildes ar aprakstu, un komentāri visi citā entītē ar savu TEXT lauku un ārējo atslēgu uz bildžu entītēm.

Uztaisi skriptu, kuram padod bildes id un izšķirtspēju kādu vajag, un tad tikai tajā skriptā nolasi bildi un pamaini izšķirtspēju. Protams, būs noslodze uz serveri, ja daudzi lietotāji kačās dažādu izmēru bildes, tāpēc pie uploada vari saglabāt bildes jau dažādos izmēros