Vliv počtu sloupců na výkon – MySQL – Fórum – Programujte.com

Ahoj neznáte nějaké srovnání vlivu počtu sloupců na práci s tabulkou? Potřebuji v tabulce mít až 500 sloupců ale většinou budu vybírat do dvaceti. Máte s tím někdo zkušenosti? Předem děkuji za odpověď.

500? Na co? Aby to nebyla nějaká prasárna.

To Figa : Zkus se znovu zamyslet nad strukturou databáze. V naprosté většině případů se dají takto široké tabulky rozdělit na několik menších nebo se to dá obejít. Ideálně trochu popiš problém, který řešíš.

To Figa : Zavání to opravdu špatný návrhem a to velmi.

Tak jsem to promeril a selecty jsou asi dvakrát tak pomalejší 1 sloupec versus 250. No ono je to docela složité na popsání a prasarna to trochu je. Snazim se udelat naprosto univerzalni system pro zobrazovani cehokoliv. V systemu jsou nejake polozky a ty polozky mohou mit nekonecne mnoho ruznych parametru ktere jsou definovany uzivatelem. Tak jsem to vyresil tak, ze je tabulka parametru kde jsou jejich vlastnosti a pri vytvoreni parametru se prida sloupec do tabulky polozek(vim je to prasarna ale nenapadlo me nic jineho). Ovsem to se zkomplikovalo, kdyz jsem polozky a parametry rozdelil do kategorii a kazda muze mit uplne jine parametry. Tim padem muze byt v tabulce polozek spousta sloupcu s hodnotami ktere jsou pro tu polozku zbytecne. Kdyz jsem pocital pocet parametru tak realne asi 100(sloupcu). Zkousel jsem jiz mnoho zpusobu ja to vyresit, ale tenhle byl asi s nejmensimi kompromisy. Rad si vsak necham poradit. Dekuji.

EDIT: Napadlo me ze by nektere parametry mohli byt stejne pro vice skupin cili by se redukoval pocet sloupcu klidne na polovinu prtz kdyz budete mit napr automobily a nakladni automobily tak 3/4 parametru je stejnych. Vim ze to stale neni idealni, ale fakt nevim jak to jinak realizovat.

To Figa :
Zobrazování čehokoliv?
Nechápu, proč by měl být systém, který je univerzální, být tak strašně neuniverzální!
Proč musí mít všechno, než ho začnu používat. Proč prostě nezačne reagovat až na nějaké vstupy a nevytvoří databázi na základě vstupů. V životě si neumim představit, že bych měl něco , co je připravený na všechno tak, že bych s sebou tahal 10x tolik věcí na nic. Krom toho by nikdy takovým stylem nebyl připraven na všechno.

Viděl jsem rekord, jaký udělala firma Victorinox (Švýcarské nože), byl to nůž který měl víc než snad 130funkcí - ale ten "KAPESNÍ" nůž nebyl použitelný, protože měl na šířku asi 15cm a vážil Bůh ví kolik.

Prostě udělej něco, co tabulky v db vygeneruje na základě vstupů, jinak je tvoje práce cestou do záhuby.

No ona se ta db vygeneruje, až na základě vstupu, ale prostě tam těch sloupců stejně bude minimálně 50 a podle těch měření to nakonec není nic strašného. S tím nožem je to krásné přirovnání a plně s ním souhlasím. Ta aplikace má být něco jako inzertní systém a uživatel bude moci inzerovat v podstatě cokoliv od aut, přes oblečení po reality. Jenže aby se to dalo nastavit, tak to potřebuji univerzální. Pokud těch kategorií bude hodně tak se to může rozdělit na víc databází a je to vyřešené. Nebo je to až taková prasárna a měl bych to předělat? Jinak moc děkuji za reakce.

To Figa : inzertní systém... Ten přeci nemusí mít tolik sloupců a tabulek. Každá věc se dá popsat několika hlavními rysy.

co to je, výrobce, typ, barva, a pár jiných vlastností, které se dají spočítat na prstech jedný ruky.
Je skoro jedno, jestli tam vrazim panenku, auto, zmrzlinu nebo planetu.

Pak si akorát uděláš nějakej identifikační sloupec a v nějaký jiný, na toto připravený tabulce budeš mít ke každému id určitou kategorii. TŘEBA

To co vymýšlíš je přece aukro, eshopy, ...

Nějaké věci ano ale u aut jsem jich napočítal třeba 40(bral jsme úplně všechno) a to bude záviset na uživateli, čili si nemůžu dovolit ho nějak omezit. Pokud toho bude mít málo tak vůbec nevadí způsob jaký mám pokud toho bude více(hodně) může si to rozdělit na více db.

To Figa : Možno ti poradím zle ale....Ak chceš aby bolo všetko v réžii užívateľa a užívateľ by mohol teoreticky pridávať "nekonečne veľa" parametrov tak vytvor jednu tabuľku kde budú položky a druhú tabuľku kde budú parametre, kde pri pridaní ďalšieho parametru sa ti pridá nový záznam do tabuľky parametre, kde táto tabuľka bude obsahovať aj stĺpec ktorý bude odkazovať na id položky......dúfam, že som to vysvetlil zrozumiteľne a nie je to ešte väčia "prasárna" :D

Figa napsal:
Nějaké věci ano ale u aut jsem jich napočítal třeba 40(bral jsme úplně všechno) a to bude záviset na uživateli, čili si nemůžu dovolit ho nějak omezit. Pokud toho bude mít málo tak vůbec nevadí způsob jaký mám pokud toho bude více(hodně) může si to rozdělit na více db.

to jozo0025: to nejde už jsme zkoušel blbě se z toho načítá a upravuje, ale díky.

to Spectator: Špatně jsi mě pochopil. Ty parametry volí admin(nazýval jsem ho uživatel) uživatelé pak jenom vybírají z možných parametrů. Ano uživatel může napsat do kolonky popis co chce ale z toho se hůře vyhledává filtruje atd.

tak si dej do jednoho sloupce jen řetězec a ty parametry něčim odděluj, v PHP to potom Explodem rozdělíš do pole...

500 sloupcu v jedne tabulce? Rika ti neco slovo normalizace?

#14 Hoffmann
A tobě není blbý odpovídat na 3 roky staré vlákno?

500 sloupcu. No, ono to jde udelat. Asi to bude trosku domonatne, spis takovy hruby nacrt

tabulky:
- seznam tabulek (id tabulky, popis) 1, ma tabulka
- seznam typu sloupcu (id typ, id typ tabulka popis) 1, 1, text; 2, 1, radek; 3, 2, telefon; ...
- seznam sloupcu (id sloupce, id typ, popis) 1, 1, muj sloupec
vlastni tabulku)
- spojeni s tabulkou (id tabulky, id sloupce) 1, 1
- seznam jazyku (id jazyk, popis) 1, anglictina; 2, spanelstina
- seznam sloupcu data text (id data, id sloupce, id jazyk, data) - textove sloupce, moznost prekladu do vice jazyku
- seznam sloupcu data cisla (id data, id sloupce, data) - ciselne sloupce, preklad nepotrebuji, ale typ sql sloupce bude cislo, rychleji se to bude vyhledavat podle obsahu (tab.data=123) nez text. Podobne treba float slopuce a pod.

Otazkou ovsem je, proc to delat? Proc nepouzit k vyrobe tabulky sql prikazy pro pridani sloupce?

A pokud nemas v tabulce fulltext vyhledavani, tak vyhledavani v textovych polich bude desne pomale. Pak se tez pise o tom, ze typ VARCHAR ma urcitou delku a pak jsou typy  s promenlivou delkou. Pokud ma radek pevnou sirku, pak preskok na dalsi radek, dalsi pole pro vyhledavani se da udelat pozice + n. Kdyz je promenliva sirka, tak se musi nejdriv zjistit sirka sloupce.

Tez je mozne pro vyhledavani udelat pomocne tabulky jen s obsahem, ktery je treba. Da se to udelat fyzicky (novou tabulku) nebo virtualne (pohledy, view). Pouzivaji to treba Oracle databaze, hodne. Nastavis server tak, aby si ulozil do pameti pohled z urcite tabulky. Pokud mas dost penez, tak mas na to diskove pole, misto bezneho disku. Kdyz to delas rucne, spesl tabulkou, tak to musis obsluhovat, menit pri kazde zmene na dvou mistech. Pohledy si tusim resi sql samo. Ale raci si k tomu najdi nejake info, ja to nikdy nepotreboval resit pohledy., tak vim jen tak zbezne, jak to asi pracuje.