Jump to content
php.lv forumi

Pāris tehniski jautājumi par PHP+MYSQL


SanchoZs

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

{"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 :))

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by 2easy
Link to comment
Share on other sites

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..

Link to comment
Share on other sites

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 by 2easy
Link to comment
Share on other sites

  • 2 weeks later...

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ē?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by 2easy
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...