Nije ovo samo do MySQL-a, to definitivno rade sve row-based baze koje znam. Mislim da negde ima dokumentacija da i Oracle baza to radi (velika "oracle database"), to su pricali kad su uvodili columnar support....
Ovaj tekst sa Percona sajta je dobar, mada mator - ali neko moje iskustvo je da, kad imas 200 kolona, prelazak na tabelu od 10 plus drugu od 190 i te kako znaci. E sad, sa 10 ili 15 verovatno ne znaci puno, ali ako projektujes sad, onda bolje da projektujes za dve tabele, pa ce ova druga vremenom narasti do mnogo... opet to je iz nekog mog iskustva. Te stvari se stalno dodaju, kako projekat odmice, a 95% vremena se ne koriste.
Sto se performansi tice, po meni, ako ti 95% vremena ne trebaju sve te kolone, i mala usteda ce ti znaciti, jer stedis na 19 od 20 izvrsavanja - da bi jedno bilo nesto sporije. Po meni to nije los tradeoff.... Ja samo napominjem sad, jer je neke stvari, tipa ovoga, uvek lakse resiti na pocetku, nego posle raditi refactor. :D
Naravno, BLOB u MySQL-u to resava drugacije, sad za 5.7 izlazi i X api (ili kako se zove vec taj javascript fazon api), pa on ima neku json podrsku, sve to ima nesto svoje i neko dodatno resenje za json... Ja pricam samo ako hoces da imas row-based bazu da ima smisla ovo resiti u startu. Pazi, na toj dodatnoj tabeli ti, verovatno, i ne trebaju indexi sem po id-u iz druge tabele, tu ces ulaziti samo kad ti treba, verovatno, ceo slog i to za tacno odredjen artikal. Ono po cemu pretrazujes (cena, ima na lageru i sl). ces verovano drzati u osnovnoj artikal tabeli.
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'