jurchiks Posted August 29, 2015 Report Share Posted August 29, 2015 @daGrevis - vaina nav pašās kolonnās, bet gan to skaitā. Kas par daudz, tas par skādi. Quote Link to comment Share on other sites More sharing options...
mysql_query Posted September 11, 2015 Author Report Share Posted September 11, 2015 Nebīju domājis ka izvērtīsies tik liela diskusija. Jautājums bija tikai tāpēc lai saprastu kā labāk taistīt DB struktūru.Starp laukumiem vienā tabulā un (JOIN LEFT,...) ir 50/50 abiem ir savi plusi un mīnusi. It kā labāk ir JOIN izmantot, bet atkal atkarībā no situācijas. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted September 18, 2015 Report Share Posted September 18, 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 .. Par šo tēmu ir laba grāmata High Performance MySQL un arī citas. No ātrdarbības viedokļa 500 lauki varētu būt ātri, bet varētu arī nebūt. Vēl jau viss atkarīgs no storage engine un row struktūras (dynamic/fixed), blokiem, utt. Praksē liela problēma varētu būt, ja dati uzaug un vajag pievienot vēl kādu lauku nepārtraucot sistēmas darbību. Quote Link to comment Share on other sites More sharing options...
Roze Posted September 21, 2015 Report Share Posted September 21, 2015 Praksē liela problēma varētu būt, ja dati uzaug un vajag pievienot vēl kādu lauku nepārtraucot sistēmas darbību. Ja ir pietiekami jauna MySQL versija (sākot no 5.6.x) salīdzinoši daudzas operācijas notiek "onlainā" un kas it īpaši (reizēm) bez vecās tabulas pārkopēšanas: https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted September 21, 2015 Report Share Posted September 21, 2015 Praktiski tas notiek tā, ka fonā tiek izveidota jauna temp tabula un tad noswapota ar shēmas tabulu. Kas, protams, priecē. Bet ja tā tabula ir ar 500 laukiem un miljoniem ierakstu, tas var būt diezgan dārgs pasākums kaut vai tādēļ, ka fonā diezgan liels process notiksies un vēl jautājums, vai un kā to var apturēt, ja nepieciešams, utt. Ar relāciju normālformu tomēr tas ir tikai viens jauns ieraksts vienā no tabulām. Tas viss jāskatās no arhitektūras viedokļa, protams. Tāda viennozīmīga atbilde te nav, bet būtu labi saprast argumentus par labu vienam vai otram risinājumam. Arguments "a man tā patika" arī ir labs arguments, tāpat kā "man tā gudri mācīja visgudrākajos kursos". Tālāk jau tā ir projekta vadītāja vai klienta problēma, kam viņš uzticējis to sistēmu būvēt. :) Priekš sevis var vispār taisīt, kā labpatīk. 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.