m8t Posted March 13, 2011 Report Share Posted March 13, 2011 (edited) Vēlos izveidot thumbs up/thumbs down skriptu. Attiecīgi, katram komentāram ir plusi un mīnusi, bet reāli es nesaprotu, kā to izveidot pareizi, lai nebūtu baigā pārslodze datubāzei. Vēl ir jāpiezīmē tas, ka, ja X lietotājs tiek dzēsts, tad visi viņa dotie plusi/mīnusi arī tiek dzēsti. Pirmā doma bija veidot kaut ko šādu: tabula `thumbs` id | type(up[1]/down[0]) | comment_id | author_user_id 1 | 0 | 19 | 88 2 | 1 | 19 | 89 3 | 0 | 20 | 89 Attiecīgi šajā tabulā varētu glabāt visus ierakstus ar plusiem/mīnusiem. Viss it kā kārtībā būtu pie maziem apjomiem, bet, ja parēķina šo visu uz 1000 lietotājiem un, pieņemsim, ka katram lietotājam būtu 1000 plusi/mīnusi. T.i. - 1 miljons ieraksti datubāzē. Tur jau baigā čakarēšanās sanāktu, velkot laukā to visu no datubāzes, paņemtu kādu nesmuku laika daudzumu. Otrā doma: tabula `thumbs` id | thumbs_up | thumbs_down | comment_id | down_users_id | up_users_id 1 | 2 | 5 | 993 | .6.8.9.4.5. | .114.54. 2 | 3 | 4 | 823 | .1.8.4.2. | .172.54.98. Šajā variantā varētu vilkt laukā tikai vienu rindu pie katra komentāra. Te gan būtu jāvelk visa tabulas rinda, ne dbrows. Ja tiktu dzēsts lietotājs, tad varētu iečekot un updatot visas rindas, kur ir attiecīgā lietotāja ID (%.$id.%). Lapas ielādei vajadzētu būt ātrākai. Plusu/mīnusu pievienošanai mazliet lēnākai (nedomāju, ka ātrums dramatiski samazināsies, jo reāli ir tikai jāizvelk konkrētā rinda un jā'updato tā ar +1 plusu/mīnusu un "$userid."). Lietotāju dzēšana te noteikti būs ļoti lēna, bet, ja tā ir tikai administācijas iespēja un tiek izmantota ļoti reti - būtībā tā nav problēma. Vai labāks veids par šiem pastāv? Kāds ir jūsu viedoklis? Edited March 13, 2011 by m8t Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 13, 2011 Report Share Posted March 13, 2011 Thumbs( value [ -1 , 1 ], user_id, comment_id, primary key( comment_id , user_id ) ); Comments( comment_id total_thumbs ... cits stuffs ) Es turētu kopējo komenta vētējumu pie komentiem , un pie katra balsojumaa pārbaudītu , vai neeksistē jau ieraksts Thumbs tabulā. Nav jegas no atsevišķa ID priekš thumbiem, jo tas tāpat netisk lietots. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted March 13, 2011 Report Share Posted March 13, 2011 Vēl ir jāpiezīmē tas, ka, ja X lietotājs tiek dzēsts, tad visi viņa dotie plusi/mīnusi arī tiek dzēsti. "FOREIGN KEY's". =] Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 @wintermute Bet atkal tas ir baigais brr... parsēt cauri visam tam miljonam. Bet jā - cits variants, laikam, nav. Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 14, 2011 Report Share Posted March 14, 2011 Ne bluži. Starp citu , svarīgi : vajag PRIMARY KEY( user_id , comment_id ) un + atsevišķu indeksu priekš comment_id .. un tad nekādi miljoni tur selektēti netiek. Anyway , paskaties : Akcents diezgn specifisks , bet saturs tev noderēs. Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 @wintermute Kveriju būvēt apmēram šādi? SELECT rindas FROM Thumbs WHERE user_id='...' AND comment_id='...' Vai te reāli kaut ko vēl var saoptimizēt? Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 14, 2011 Report Share Posted March 14, 2011 No tabulas Thumbs tu praktiski nekad neko neselektē. Varbūt vienīgi tad , ja jāpārrēķina rezultāts, pēc kāda jūzera dzēšanas. Un arī tad par to drošvien atbildētu kaskāde SQL pusē. Thumbs ir paredzēts galvenokārt vertējumu reģistram. Tā kā primary key's ir unikāls, tad DB pati tev neļaus jūzerim divreiz par vienu komentāru nobalsot. Ja INSERT's iekš Thumbs nekādu kļūdu neatgriež, tad tu Comments tabulā izmani kopējo vērtējumu. Šito var norealizēt gan ar diviem query'iem , gan arī (labāk) ar SQL procedūru. Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 Tā kā primary key's ir unikāls, tad DB pati tev neļaus jūzerim divreiz par vienu komentāru nobalsot. Ehh.. nu jā, loģiski. Laikam no rīta galva vēl isti nestrādā tā kā vajadzētu. Nekas. Liels paldies. Quote Link to comment Share on other sites More sharing options...
snach15 Posted March 14, 2011 Report Share Posted March 14, 2011 Ehh.. nu jā, loģiski. Laikam no rīta galva vēl isti nestrādā tā kā vajadzētu. Nekas. Liels paldies. vakarā arī tev tas tukšais pauris nestrādā Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 @daGrevis Varbūt vari paskaidrot, kas ir tik īpašs par Foreign keys? I mean - kādēļ izmantot viņus? Vienīgā iemesls, kādēļ viņus izmantot, cik nu es esmu daudz izstudējis, ir tas, ka var smuki sagrupēt dažādas tabulas. Protams, tad arī var izmantot to fīču, ka kaut ko dzēs un dzēšas arī ieraksti, kas bija sasaistīti kopā ar to, no visām tabulām. Šī ir mana pirmā sastapšanās ar to. Burtiski, nekad agrāk par to, ko dēļ tevis izlasīju par foreign keys un tās (pat nosaukumu neatceros) DB nebiju ne dzirdējis, ne redzējis. Paldies! Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 14, 2011 Report Share Posted March 14, 2011 Es nez kāpēc iedomājos, ka tu zini, kas ir FOREIGN KEY un ko tas dara. Sāc ar to, ka cītīgi izlasi: http://en.wikipedia.org/wiki/Foreign_key ( vēlams vismaz 2x ). Nedaudz mēģināšu paskaidrot. Pieņemsim, ka tev ir tabula Comments ar lauku user_id, un tev ir tabula Users, kas satur jūzera datus un user_id . Loģiski būtu, ja tu nevarētu ievietot komentāru ar jūzeri, kurš neeksistē. Tā ir viena lieta ko nodrošina FOREIGN KEY. Un tad ir tāda lieta kā notikumi ON DELETE un ON UPDATE, kas ļauj tev automātiski mainīt datus, ja kaut kas mainās tabulā, uz kuru tu atsaucies. Piemēram, tu dzēs ierakstu no Users tabulas, un vēlies turmpāk parādīt visus tā jūzera komentārus ar autora vardu "Dzēsts lietotājs", tad tabulas definīcijā tev būs framgments: FOREIGN KEY(user_id) REFERENCES Users(user_id) ON DELETE SET NULL Un tad tu visiem komentāriem kuriem komentāru tabulā user_id ir NULL , tu parādi speciālu jūzerneimu. Nu kaut kā tā .. IMO tev vajadzētu vienārši iemācīties kaut kādus SQL pamatus. Paņem izlasi kādu grāmatu par MySQL vai PostgreSQL, tad izlasi kas ir 3NF, Un visbeidzot palasi šito grāmatu : SQL Antipatterns Quote Link to comment Share on other sites More sharing options...
daGrevis Posted March 14, 2011 Report Share Posted March 14, 2011 Piemēram, forums. Dzēšot topiku automātiski tiks dzēsti arī visi topika posti. ) Protams to var izdarīt manuāli, bet jēga čakarēties? ) Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 @wintermute Un cik es nopratu, tad, lai darbotos ar FOREIGN KEY ir jābūt InnoDB dzinim, ne MyISAM. Am I correct? Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 14, 2011 Report Share Posted March 14, 2011 Kurš pie pilnas sajēgas vispār MyISAM lieto? Tam dzinim vienīgais pielietojums ur full-text meklēšana, bet tad tev vajag glabāt tos datus divās dažādās tabulās. Tāpēc ka MyISAM nenodrošina ACID un tu nevari būt drošs, ka tas ko tu iepūt datubāzē būs arī dabūnams laukā. MyISAM ir slavens ar savu tieksmi tabulam "nobirt" tik pamatīgi, ka shēma nav pat glābjama. Nez .. Es vispār MySQL par nopietnu DB dzini neuzskatu :P Quote Link to comment Share on other sites More sharing options...
m8t Posted March 14, 2011 Author Report Share Posted March 14, 2011 He, redz, es līdz šim lietoju un dzīvoju laimīgs. Par nekā cita eksistenci nezināju ;D Kādu dzini tu ieteiktu? Vai InnoDB ir normāls? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.