Pāris tehniski jautājumi par PHP+MYSQL

[SanchoZs]

SVeiki. Negribēju piedrazot lieki. Sen aiz muguras laiki, kad visu jautāju šeit, bet ir reizes, kad vajadzīgs zinošāka cilvēka padoms.

 

Tātad procesā ir protāla veidošana. Ideiski viss vairāk vai mazāk skaidrs, bet atdūros pret pāris niansēm, ko vēlētos izprast jau sākumā.

 

1) Un mazāk svarīgais jautājums - Netā ir daudz viedokļu par attēlu izvietošanu mysql tabulā. Ir ideja, ka tur varētu izvietot thumbnailus, kas būtu maksimums 100x100 pikseļus lieli. Vai ir vērts? Pie apstākļiem pieminot, ka būs daudz pieprasījumi šāda veida.

 

2) Svarīgais. Pašlaik nevaru izlemt vienu soli db struktūrā. Lapā ir vairāki lauki, kas sastāvēs no vairākiem čekboksiem, kas apzīmēs dažādas noteikta lauka parādīšanas iespējas. Teiksim: Nosaukums - rādīt visur | rādīt a vietā | rādīt apakšā | rādīt augšā. kā labāk risināt šo stuāciju - Veidojot DB struktūrā laukus t/f katrai no iespējām vai arī vienu lauku, kurš satur skaitlisku vērtību no 1-N un ar php tiek atsijāt pēc skaitļa, kuri no laukiem ir izvēlēti. Lauku skaits būs konstants un nemainīsies biežāk par reizi nezināmā laika periodā, kurš noteikti būs vismaz gads.

 

Mazliet papildināti. Tātad:

V - 1)

Augļa nosaukums | skābs? | salds? | kauliņš ir? | serde ir?

ābols | t | f | f | t

 

Pret V - 2)

Augļa nosaukums | raksturs |

ābols | 3 |

 

un 3 stands for "t | f | f | t", bet tas netiek ņemts no db, bet gan atfiltrēt php skriptā. Cerams doma ir aptuveni skaidra.

 

Paldies jau iepriekš tiem, kuri vismaz centīsies saprast, ko es vēlos uzzināt.

[Kemito]

Nū domāju tos thumbail tev ir jēga taisīt!

 

Ja tev ir attiecīgi vaidzīgs tikai, vai lauks ir ieķeksēts vai lauks nav atļeksēts, tad jau labāk izvēlēties attiečīgi true/false vērtības!

[2easy]

1) Un mazāk svarīgais jautājums - Netā ir daudz viedokļu par attēlu izvietošanu mysql tabulā. Ir ideja, ka tur varētu izvietot thumbnailus, kas būtu maksimums 100x100 pikseļus lieli. Vai ir vērts? Pie apstākļiem pieminot, ka būs daudz pieprasījumi šāda veida.

VISAS bildes glabā folderī un pieprasa pa taisno no attiecīgā foldera. performance ftw

 

2) Svarīgais. Pašlaik nevaru izlemt vienu soli db struktūrā. Lapā ir vairāki lauki, kas sastāvēs no vairākiem čekboksiem, kas apzīmēs dažādas noteikta lauka parādīšanas iespējas. Teiksim: Nosaukums - rādīt visur | rādīt a vietā | rādīt apakšā | rādīt augšā. kā labāk risināt šo stuāciju - Veidojot DB struktūrā laukus t/f katrai no iespējām vai arī vienu lauku, kurš satur skaitlisku vērtību no 1-N un ar php tiek atsijāt pēc skaitļa, kuri no laukiem ir izvēlēti. Lauku skaits būs konstants un nemainīsies biežāk par reizi nezināmā laika periodā, kurš noteikti būs vismaz gads.

katram checkbox lai ir atbilstošs bit NOT NULL lauks tabulā. tā vieglāk būs menedžēt

[codez]

1)Man šķiet, ka īsti nav jēga, jo jākodē plus mīnus tikpat vai pat vairāk, bet performance tiek zaudēta.

 

2)Ja šos laukus nav nepieciešams indeksēt un pēc tiem būvēt kverijus, tad es parasti tādus kompleksus laukus glabāju vienā text laukā json formā, piemēram:

{"values":[0,1,1,0],"othervalues":{"height":100,"width":150,"struct":[14,15,16,38]}}

šādā gadījumā ir viegli manupelēt ar mainīgu parametru skaitu, saglabājot labu ātrdarbību.

[SanchoZs]

1) Par bildēm skaidrs. Tas mani liks mierā uz visiem laikiem.

 

2) Codez, Tavu variantu īsti līdz galam neizpratu, bet, ja bieži tiks pieprasīta tā informācija, tad cik noprotu jēgas nav manai idejai.

 

Paldies Jums par viedokļiem.

[2easy]

{"values":[0,1,1,0],"othervalues":{"height":100,"width":150,"struct":[14,15,16,38]}}

šādā gadījumā ir viegli manupelēt ar mainīgu parametru skaitu, saglabājot labu ātrdarbību.

njaa tā jau, protams, var darīt, ka tos laukus, kurus vajag iekš WHERE vai ORDER BY, tos definē kā atsevišķus laukus, bet pārējos sabāž vienā: Json text

 

gaumes lieta, bet man gan labāk patīk, ka tabulām ir dažādas kolonnas :))

[codez]

JSON - javascript objektu pieraksta forma.

json_encode() - funckija, kura php array pārvērš json stringā. pretējā json_decode().

 

Tad tev tabulā ir viens lauks, piemēram, data, kurā tu glabā šo JSON stringu, kurš var kodēt kā vienkāršu masīvu, tā asociatīvu masīvu, vai veselu objektu koku.

 

$arr=array(0,1,1,0);

$data=json_encode($arr); //$data būs "[0,1,1,0]", šāadu arī glabā laukā.

 

kad nolasi $data no mysql, tad

$arr=json_decode($data,true);

echo $arr[1]; //1

 

šis bija piemērs ar parastu viendimensiju masīvu, bet šādi tu vari glabāt arī sarežģītākas struktūras, turklāt, ja aplikācija ir diezgan ajaxīga, tad šādus datus uzreiz var echot klientam, kur js tos bez problēmām apstrādās.

[Kaklz]

Dažādās pazīmes var glabāt parastā int laukā, līdzīgi kā tas ir ar unix tiesībām:

 

1. pazīme - 1

2. pazīme - 2

3. pazīme - 4

..

n. pazīme - 2 pakāpē n-1

 

Lai saglabātu vairākas pazīmes vienkārši summē ciparus. Teiksim ja tev ir pazīme 1 un 3, tad db glabā skaitli 5. Pēc tam var tīri vienkārši ar bitshift operācijām pārbaudīt, vai konkrētā pazīme konkrētajam objektam ir, vai nē. Pēc šāda paša mehānisma darbojas arī MySQL SET datu tips, bet ja grib to izmantot, tad ir mazliet čakars ar papildus pazīmju pievienošanu, jo tad ir jālabo db struktūra.

[2easy]

Lai saglabātu vairākas pazīmes vienkārši summē ciparus. Teiksim ja tev ir pazīme 1 un 3, tad db glabā skaitli 5. Pēc tam var tīri vienkārši ar bitshift operācijām pārbaudīt, vai konkrētā pazīme konkrētajam objektam ir, vai nē.

tā bija normāla pieeja 70. un 80. gados, kad datora atmiņa bija relatīvi dārga. savukārt mūsdienās datus var atļauties glabāt ne tik ļoti vietu taupošā formātā. protams, ja kko vajag push to the limits, tad jau var arī daudzus bitus dzīt iekšā vienā tinyint/smallint/mediumint/int kolonnā ;)

Edited March 3, 2010 by 2easy

[bubu]

Ja to čekbokšu skaits un nozīmē nemainīsies, tad glabā tos MySQL SET'ā - tas db glabāsies tieši kā Kaklz stāsta. 4 baitos varēs saglabāt līdz pat 32 čekbokšiem.

Ja tie čekbokši mainās un tad jātaisa N:N relācija - datu tabula un čekbokšu tabula, pa vidam liekot starptabulu ar saitēm.

 

2easy: ja runājam ne par DB, tad arī mūsdienās šo pieeju joprojām daudz un dikti izmanto visdažādākajās programmās (nerunāju par php). Daudz efektīvāk ir izpildīt vienu and operāciju, nekā ciklu pa 32 elementiem, lai pārbaudītu vai elements ir izdalīts/eneiblots/utt..

[2easy]

tas gan ^^

iekš tā paša error_reporting() tā bitveidīgā setošana ir diezgan ērta

 

man vnkārši vajadzēja sabiezināt krāsas, lai kāds pateiktu kādu labu pretpiemēru ;)

Edited March 3, 2010 by 2easy

[SanchoZs]

Tā, man atkal ir jautājumi. Lielā web bāzētā projektā - ko labāk izmantot - to pašu php+mysql vai domāt par kādu citu risinājumu.

 

Projekts iesākumā nav paredzēts apjomīgs, bet paredzēts, ka to vienlaicīgi lietos aptuveni 1000 lietotāju. Kādi ir ieteikumi šāda apjuma projektu iztrādē?

[Aleksejs]

Neatkarīgi no tā vai izvēlēsies php+mysql Tev būtu jāpadomā par aparatūras (tajā skaitā infrastruktūras komponenšu - switchu rūteru utt) aizstājamību un slodzes dalīšanu. Tāpat viss ir atkarīgs no tā, cik resursrijīgs ir pats projekts - statiskai lapai ir vienas prasības, bet reāllaika massivemuptiplayer spēlei ir pavisam citas prasības.

Atkarībā no prasībām un pieejamajiem rewsursiem tad arī jādomā tālāk. PHP viet«ā tik pat labi varētu būt kāda cita serverpuses valoda (Python/Ruby/Java/.NET)... MySQL vierā kāda cita RDBVS (PostgreSQL, Oracle, MSSQL, Firebird) vai pat (atkarībā no specifikas) ne-relāciju datubāze...

 

Kamēr nav specifiskāka apraksta tam, kas domāts, tikmēr...

[SanchoZs]

Tā drīzāk būtu pielīdzināma "reāllaika massivemuptiplayer spēlei". Kāpēc tāds jautājums? Iekš datuves pirms pāris dienām lasīju diskusiju, kura risinājās starp datuviešiem un Libertu. Tur arī risinājās saruna par to, ka tik apjomīgam projektam ar pliku php un mysql var gadīties daudz par īsu.

 

Kādas ir reālās iespējas un vajadzības gan sistēmas ziņā, gan programmēšanas valodu izvēlē, lai ar apjomīga projekta izstrādi neuzdurtos uz zemūdens akmeņiem?

[2easy]

tev jau teica, ka problēma ir nevis programmēšanas valodā vai sistēmā, bet dzelšos. tu vari uzlikt kaut vai vienu vienīgu htm failu ar tekstu "hello world" uz jebkādas sistēmas (OS), bet ja to katru sekundi pieprasīs 1000000x, tad nebūs nekādi zemūdens akmeņi, bet vesels sēklis

 

kr4 kodu var optimizēt visādīgi, taču kad visefektīvākie algoritimi jau ir pielietoti un viss iespējamais kešojamais kontents ir nokešots (glabāts nevis kkur uz hdd, bet uzreiz atmiņā un gatavs padošanai/servošanai), tad neko tālāk kodā vairs optimizēt nevar un ir jāķeras pie hardware upgrade. jo ja tai sistēmai ir jādara kkāds darbs, tad neatkarīgi no programmēšanas valodas, darbu izpilda servera cpu un cik ātri tas ar to tiek galā, tik ātri arī viss notiek + network traffic

Edited March 13, 2010 by 2easy