Aiviss Posted March 22, 2011 Report Share Posted March 22, 2011 (edited) Labdien, Situācija sekojoša: 1. Ir tabula, kurā glabājas ieraksti. 2. Ir tabula lietotāji (tas laikam nav īpaši saistoši ar šo, bet...) Kad konkrētais lietotājs ir apskatījis "tabulas 1" ierakstu, viņam nedrīkst to vairs rādīt -> respektīvi konkrētā ieraksta status šim user ir 1. (status, ka viņš ir apskatījis) To var risināt šādos veidos (manuprāt): 1. veids 3. Tabula, kur glabājas informācija -> user_id | ieraksta_id | status un tad katru reizi, šķirstīt cauri Tabulu un pārbaudīt vai konkrēto ierakstu, konkrētais lietotājs ir redzējis. Bet ja lietotāji ir piem., 2000 un ieraksti 100'000, tas nebūs ilgi? jo tad tabulas 3. ierakstu skaits teorētiski var sasniegt 200'000'000 2. veidsKatram lietotājam veidot savu tabulu, kura satur informāciju, kuru ierakstu viņš ir skatījis.... Bet tad sanāk 2000 tabulas. Kādi Jūsu varianti? Varbūt es domāju nepareizā virzienā? + varbūt katram lietotājam savu "flat file" ? Edited March 22, 2011 by Aiviss Quote Link to comment Share on other sites More sharing options...
rATRIJS Posted March 22, 2011 Report Share Posted March 22, 2011 (edited) Pirmais variants protams. Nekas lēns tur traki nebūs. Ja vēlāk būs vajadzība - uzlabos. + apdomā vai tev vispār vajag statusu. Ja jau ir tikai apskatīts vai nē. Aka - ja ir apskatīts tad attiecīgs user_id:story_id ieraksts (abu apvienojums ir arī unikāls ID), pretējā gadījumā nav apskatīts. Edited March 22, 2011 by rATRIJS Quote Link to comment Share on other sites More sharing options...
m8t Posted March 22, 2011 Report Share Posted March 22, 2011 Tabula `lasijumi` userid | lasijumi 1 | .234.566.783.473. 2 | .567.2222.64.144. izvelc rindu, kura pieder konkrētam lietotājam un tad tik ar explode(). Quote Link to comment Share on other sites More sharing options...
Aiviss Posted March 22, 2011 Author Report Share Posted March 22, 2011 Liels paldies Jums abiem! Quote Link to comment Share on other sites More sharing options...
rATRIJS Posted March 22, 2011 Report Share Posted March 22, 2011 m8t variants uzsprāgs pie liela lasījumu skaita. Piemēram, ja lietotāji ir izlasījuši 1000 (un vairāk) rakstus. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted March 22, 2011 Report Share Posted March 22, 2011 Vispārīgā gadījumā noteikti 1 scenārijs Par detaļām var apdomāt šādas tādas optimizācijas, lai it kā būtu vieglāk: 1) rakstīt starptabulā tikai tos ierakstus, kur lietotāji jau ir apskatījuši - ja lielākā daļa savā mūžā apskatīs tikai dažus ierakstus - nebūs jāveido bezjēgā daidz ieraksti ar 0 2) datu atlase ir zibenīga - ir takš tādas lietas kā indeksi. 3) m8t piedāvātais variants arī ir izskatīšanas vērts, bet ar šādām struktūrām vienmēr ir jābūt ļoti uzmanīgam. Explode - ir PHP specifiska lieta, ne visās programmēšanas valodās - nemaz nerunājot par SQL tas būs tik vienkārši. Otra lieta šeit ir relatīvi viegli iegūt lietotāja apskatītos ierakstus BET, lai iegūtu konkrētam ierakstam tos lietotājus, kuri to ir apskatījuši ir nevājš čakars - tā kā jāskatās pēc prasībām, ko Tev vajag un vai šāda struktūra der. Gints Plivna http://datubazes.wordpress.com Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 22, 2011 Report Share Posted March 22, 2011 Sorry, Gint, bet m8t variants NAV apskatīšanas vērts, jo tas ir nelietojams. Tā tabula kļūst neizmantojama SQL pusē ( ne jau tu izmantosi LIKE priekš SELECTa ), un rada papildus slodzi uz skriptu: explode + in_array Quote Link to comment Share on other sites More sharing options...
daGrevis Posted March 22, 2011 Report Share Posted March 22, 2011 Izskatīšanas vērts, nevis lietotjams. P.S. 2000 tabulas (katram lietotājam Sava)? He, he... Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted March 22, 2011 Report Share Posted March 22, 2011 Sorry, Gint, bet m8t variants NAV apskatīšanas vērts, jo tas ir nelietojams. Tā tabula kļūst neizmantojama SQL pusē ( ne jau tu izmantosi LIKE priekš SELECTa ), un rada papildus slodzi uz skriptu: explode + in_array Nekad nesaki nekad ;) Es, jo vecāks nāku, jo vairāk visādas dīvainības esmu redzējis un mazāk kategorisks uz "nekad to nelietot" palieku. Jā es personīgi šo variantu nelietotu. Bet, ja kāds spētu pamatot, kāpēc tieši šai gadījumā tas viņam derētu, un kāpēc visi pretargumenti šai gadījumā nav būtiski, tad kāpēc ne? T.i. kaut kādas dīvainības lietošanai es personīgi gribu redzēt ļoti pamatotus argumentus, ja tādi ir, tad iespējams to var izmantot. Gints Plivna http://datubazes.wordpress.com Quote Link to comment Share on other sites More sharing options...
Kverkagambo Posted March 22, 2011 Report Share Posted March 22, 2011 Var jau pirmo variantu apvārst: pievienojot ierakstu, starpniektabulā izveido ierakstus katram lietotājam. Pēc tam pārbauda, vai tāds ieraksts pastāv, un ja tā, parāda ierakstu un izdzēš ierakstu no starpniektabulas. Tā visu laiku tabulas izmērs samazināsies. Vēl var arī apvienot abus variantus: Pievienojot ierakstu, tam pieliek 1. statusu, glabā lietotāju lasījumus pirmajā starptabulā, kad izlasījušo skaits pārsniedz pusi, maina statusu uz 2., nodzēš lasījumus no pirmās startabulas un ieraksta visus neizlasījušos otrā. Tālāk kā teikts iepriekš. Quote Link to comment Share on other sites More sharing options...
wintermute Posted March 22, 2011 Report Share Posted March 22, 2011 Patiesībā šitas viss ir bullshits. Aiviss, ko tiesi tu tur meģini uztaisīt ? Man atkal ir sajūta ka tiek prasīts bugfix's priekš ķļūdaina risinājuma, kurš izdomāts nepareizi nodefinētai problēmai. Vai tas ir obligāts nosacījums, ka lietotājs var izlasīt ziņu vienu , un tikai vienu , reizi ? Ja tāda nosacījuma nav, tad daudz optimālāk būtu glabat "izlasīts" statusu ~200 pēdējām ziņām, un pārējās attēlot kā arhīvu. Tad 1. piemēra tabulas pieeaugums ir lineārs , nevis eksponenciā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.