Sasa Posted August 27, 2015 Report Share Posted August 27, 2015 Tāpēc pie kolonnām jāliek klāt komentāri. Quote Link to comment Share on other sites More sharing options...
Blitz Posted August 27, 2015 Report Share Posted August 27, 2015 Ja objektu raksturo 500 skalari propertiji tad es arī taisītu 500 kolonas Quote Link to comment Share on other sites More sharing options...
briedis Posted August 27, 2015 Report Share Posted August 27, 2015 Ja objektu raksturo 500 skalari propertiji tad es arī taisītu 500 kolonas Iedomu pasaulē - jā. Reālā dzīvē nez vai atradīsies kas tāds, kam ir 500 tik ļoti dažādi propertiji kurus nevar normalizēt/grupēt :) Kā matemātikas uzdevumos, kad Jānītim ir divas tonnas ābolu, bet ilzītei tikai 200 kg Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 ^ Tā arī rodas tādi over-engineringi kā leaf cms. Ja kaut kas ir pārāk vienkārši obligāti vajag uztaisīt sarežģītāk, lai tik kolēģi nepadomā, ka necert zivi Quote Link to comment Share on other sites More sharing options...
briedis Posted August 27, 2015 Report Share Posted August 27, 2015 ^ Tā arī rodas tādi over-engineringi kā leaf cms. Ja kaut kas ir pārāk vienkārši obligāti vajag uztaisīt sarežģītāk, lai tik kolēģi nepadomā, ka necert zivi Tu kaut kādu bezsakaru runā te. Labāk ir, kad phpdoc modeļa propertiji neielien vertikāli ekrānā? Kurš vispār tādu kluci var uzturēt? Te ir ~80 propertiji (nav kolonnas visas, bet dažiem gribētos pat vairāk), un jau ir psc kkam izsekot līdzi, pat ar IDEi. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 Nopērc lielāku monitoru. Es jau iepriekšējā lapā izskaidroju kāpēc ir bezjēdzīgi dalīt pa tabulā, tikai tāpēc, ka kādam šķiet, ka lauku par daudz. Perfomance un programmēšanas ērtums. Programmējot tu to dari, lai tas darbotos ātri un nerītu mežonīgi daudz servera resursu, nevis lai apmierinātu savus koda fetišus Quote Link to comment Share on other sites More sharing options...
briedis Posted August 27, 2015 Report Share Posted August 27, 2015 Programmējot tu to dari, lai tas darbotos ātri un nerītu mežonīgi daudz servera resursu, nevis lai apmierinātu savus koda fetišus Nu te sanāk forša pretruna. Milzīgi kvēriji, daudz rezultāti tiek atgriezti, milzīgi masīvi. Selektīvi selekti, tu saki? Aha, kuram gan negribas uzskaitīt 30 kolonnas ar roku, un tad, kad kaut kas mainās, tad labot 20 vietās :) 99.9% gadījumu kodē, lai kods būtu viegli saprotams, uzturams, Nevienam nav vajadzīgi super duper mega ģeniāli algoritmi, kurus neviens nesaprot, bet redz darbojas par 10ms ātrāk. Dzelži ir lēti... Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 Šis vienkāršums un mežonīgā perfomance SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, t.field500 ASC; Pret šo neglītumu un neidomājamu bremzi SELECT id FROM tabula1 LEFT JOIN tabula2 ON tabula1.id=tabula2.id LEFT JOIN tabula3 ON tabula1.id=tabula3.id LEFT JOIN tabula4 ON tabula1.id=tabula4.id LEFT JOIN tabula5 ON tabula1.id=tabula5.id LEFT JOIN tabula150 ON tabula1.id=tabula5.id LEFT JOIN tabula500 ON tabula1.id=tabula5.id WHERE (t1.field1='v1' AND t2.field2='v2') OR t3.field3='v3' AND t4.field4 LIKE '%v1%' ORDER BY t5.field22 ASC, t150.field150 DESC, t500.field500 ASC; Kurš labāks? Quote Link to comment Share on other sites More sharing options...
Roze Posted August 27, 2015 Report Share Posted August 27, 2015 Tie visi izdomātie kolonu limiti ir smieklīgi. Ja man tiešām vajag 500 kolonnas es tās likšu vienā tabulā. Nevis speciāli domāšu dalīšu pa tabulām, tikai lai ievērotu izdomātu limitu. Ja būs vajadzība filtrēt pēc 5 laukiem, kur katrs ir savā tabulā, tad man nāksies tās visas tabulas JOINot un tad filtrēt. Ja vēl vajadzēs pēc tām pašām kolonnām ORDER BY, tad tas query būs ļoti, ļoti lēns. Programmētāju ietiepība ar reizēm ir smieklīga (reizēm gan nāk dusmas u.c. izpausmes). Bet nu atbilde par to, kas ir labāks un ātrāks nav viennozīmīga, kaut vai dēļ šādiem jautājumiem: - Vai atlasīšanas kveriji ir jāveic pēc visiem 500 laukiem? Ja jā un ja tev ir 500 kolonnu tabula, tad arī no tādas selectējot pēc kaut kādiem 5 laukiem kverijs būs "lēns", jo lai gan tagad ir nedaudz labāka situācija ( https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html) tad principā vai nu tev jātaisa tabulai 500 indeksi (pie kam innodb var būt tikai 64) vai jāizvēlas uz kuriem likt uz kuriem nē, bet galugalā pasākums nekāds ideāls nav. - Vai ieraksta visas vērtības/kolonnas vienmēr satur vērtību? Ja nē, tad atkarībā no tā kāds % ir aizpildījumam var tikt zaudēts diezgan daudz diskvietas. Tāpēc jau arī eksistē dažādi NoSQL, kā arī veidi tradicionālajās RDBMS ( piem https://mariadb.com/kb/en/mariadb/column_json/) kā optimālāk iebakstīt objektam 500 vērtības. Quote Link to comment Share on other sites More sharing options...
Roze Posted August 27, 2015 Report Share Posted August 27, 2015 Šis vienkāršums un mežonīgā perfomance SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, t.field500 ASC; Pret šo neglītumu un neidomājamu bremzi SELECT id FROM tabula1 LEFT JOIN tabula2 ON tabula1.id=tabula2.id LEFT JOIN tabula3 ON tabula1.id=tabula3.id LEFT JOIN tabula4 ON tabula1.id=tabula4.id LEFT JOIN tabula5 ON tabula1.id=tabula5.id LEFT JOIN tabula150 ON tabula1.id=tabula5.id LEFT JOIN tabula500 ON tabula1.id=tabula5.id WHERE (t1.field1='v1' AND t2.field2='v2') OR t3.field3='v3' AND t4.field4 LIKE '%v1%' ORDER BY t5.field22 ASC, t150.field150 DESC, t500.field500 ASC; Kurš labāks? Šis ir nekorekts salīdzinājums, jo neviens (parasti) tā netaisa. Tabula parasti ir tikai viena (nevis tabula1, tabula2, tabula500) un satur 3 laukus: objekta_id | propertija_nosaukums | propertija_vertiba Un tad selecteejot WHERE propertija_nosaukums = 'kautkas' AND propertija_vertiba = 'kautkaada' var atlasiit visus nepieciešamo objektu_id (kuriem tad piejono galveno tabulu(as) - attiecīgi tikai 1 JOINs) .. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 objekta_id | propertija_nosaukums | propertija_vertiba Ja ir šis modelis, tad selektēšana pēc vairākiem propertijiem ar AND arī ir čakarīga. Papildus jāskatās vai visi pieprasītie propertiji ir atlasījušies, nevis tikai viens. Quote Link to comment Share on other sites More sharing options...
Roze Posted August 27, 2015 Report Share Posted August 27, 2015 Protams, tāpēc jau ir svarīgi ko, kā un kas ar tiem 500 laukiem jādara. Mans komentārs bija tikai par to, ka salīdzinājums nav visai korekts un kverijam:SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, nekādus sakarīgus indeksus ņemot verā MySQL īpatnības uzlikt nevar (ja tomēr, tad gribu noteikti redzēt (nopietni!) :) ) un nekāda "mežonīga" performance nebūs - protams, ja ieraksti būs zem < ~1mio (nu vai tabulas izmērs salien servera ramā (filecache)) un mysql instance nebūs kaut kāds diloņa slimnieks (nemaz nerunājot, ja kverijs iekešojas), tad protams izpildīsies arī samērojamā laikā (lasi, pietiekami ātri) jebšu tas saucas 'full table scan'. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 Protams, ierobežojumi ir abos gadījumos. Es arī neesmu saskāries ar 500 laukiem tabulā, bet ticu, ka īpašos gadījumos ir vajadzība, tāpēc arī uzsvēru, ka nevajag balstīties uz iedomātie ierobežojumiem. Kāpēc selektējot pēc vairāk par 5 laukiem query būs lēnaks? Slinkums tagad lasīt to linku Quote Link to comment Share on other sites More sharing options...
Roze Posted August 27, 2015 Report Share Posted August 27, 2015 Īsumā - MySQL jēdzīgi māk izmantot tikai vienu tabulas indeksu (eksistē tur protams tagad visādas index-merge optimizācijas) bet in general ideja ir tāda - proti ja WHERE kolonna ir vienā indeksā bet ORDER vai GROUP kolonna ir citā indeksā tad ir "ziepes", atkarībā no mysql optimizera sajūtām var tikt izmantots tikai tas indekss kas ir WHERE nosacijumā un rezultāti kārtoti "fiziski" jebšu otrādi - mysql var izdomāt ka sasortēt tabulu ar miljons ierakstiem ir ātrāk un tad skriet tai cauri "manuāli" (row-by-row) pārbaudot katru vērtību un atlasīt tikai konkrētus ierakstus. Savukārt kombinētos indeksus lielam lauku skaitam ir sarežģīti uzlikt - piemēram, ja ir indeks uz (kolonna1,kollona2, kollona3) tad kverijs WHERE kolonna1 = 'lala', kolonna2='blabla', ODER BY kolonna3 ir OK, bet kverijs WHERE kolonna1 = 'lala', ODER BY kolonna3 vairs nē (proti indekss tiks izmantots, taču tikai atlasei, bet ne kārtošanai), tāpat WHERE kolonna2='blabla', ODER BY kolonna3 (šeit vispār nē) utt... Protams, ja kveriji ir vienmēr fiksēti (noteikti (un ne pārāk daudz variacijās) WHERE/ORDER nosacījumi) tad ir savādāk, bet praksē parasti nācies sastapties ar to ka tos WHERE/ORDER ik pa laikam maina vai arī nepieciešams tik dinamiski kārtot, ka puse no sākotnēji uzliktajiem tabulas indeksiem ir vai nu lieki vai pārklāj citus vai neizmantojas vispār. Tā kā bundža ar daudz tārpiem .. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted August 27, 2015 Report Share Posted August 27, 2015 Uz katru lauku indeksus neliks. Indeksu pieskaņos vajadzīgajā atskaitēm Un kā ir ar šādu situāciju, tas var radīt kaut kādas problēmas? indekss1 (lauks1, lauks2, lauks3) indekss2 (lauks2, lauks3, lauks4) Tu dažas ļoti labas nianses izstāstīji 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.