Autor Zpráva
joe
Profil
Ahoj,

Resim jednu vec, mam profily uzivatelu, kde si muzou kde co vyplnit a tabulka se mi rozrostla na 80 sloupecku. Je to moc na tabulku s uzivateli, pripadne jak byste to resili vy?
Pripadne bych to mohl mit takto:
Tabulku s uzivatelama (asi 15 sloupecku)
Tabulku s vyplnenym profilem (tak kolem 60 sloupecku)

Ale na kazdou zmenu v profilu, bych musel kontrolovat, jestli existuje uzivatel v tabulce s profilama, pak bych provedl jen update, jinak tam vlozil cely radek.

Ma nejaky vliv na rychlost, kolik ma tabulka sloupcu, kdyz z ni vybiram vzdy maximalne 10 - 20 sloupcu (treba kdyby mela 150 sloupcu) nebo na tom nezalezi.

Mohl by mi jeste nekdo zkusenejsi rict, jak se pouziva v SQL EXPLAIN? Hledal jsem, ale nejake rozumne vysvetleni jsem moc nenasel. Da se nejak zjistit jake je to zatizeni na databazi, dotazy..atd.
Diky za reakce.
CommanderZ
Profil *
Rychlost to ovlivni, ale nebude to nejak kriticke. Celkem urcite to pujde lip nez kdybys k tomu joinoval dalsi tabulku. 80 sloupecku je dost, ja mel nejvic 50 a bylo to vpohode. Horsi je kdyz pak mas nejaky dotaz ktery taha data z 10 ruznych tabulek na zakladu nejakych slozitych podminek.

Samozrejme se vzdy snaz tech sloupcu vybirat co nejmin.

Explain ti zjisti nejake detaily ohledne provadeni prikazu, vykon ti sam nezhodnoti, da ti jen indicie. Podivej se na to do ofiko dokumentace. Mereni rychlosti delej prez nejaky programovaci jazyk (php) - dej ten prikaz provest tisickrat a uz ziskas pomerne smerodatne udaje.
djlj
Profil
Je to moc na tabulku s uzivateli
Ne.

Ma nejaky vliv na rychlost, kolik ma tabulka sloupcu, kdyz z ni vybiram vzdy maximalne 10 - 20 sloupcu (treba kdyby mela 150 sloupcu) nebo na tom nezalezi.
U těchto čísel na tom nezáleží.

Mohl by mi jeste nekdo zkusenejsi rict, jak se pouziva v SQL EXPLAIN?
http://php.vrana.cz/ukazka-pouziti-indexu.php
grim
Profil *
joe
Jestli to dobře chápu tak máš např. pro přístup do nějaké sekce zvlášť sloupec?
...já tohle řeším tak, že mám tabulku uživatelů a tabulku s profily. Tabulka profil má jen 3 sloupce
a jeden z nich je práva kam ukládám číslo sekce a práva na čtení zápis a mazání, takže to ve výsledku vypadá nějak takhle:
Profily
id     nazev     prava
1      xxx         2100,3;3000,1;4000,0
tiso
Profil
grim - máš to zle navrhnuté, hovoria ti niečo normálové formy a normalizácia databáz?
ninja
Profil
joe: Tebou navrzene rozdeleni do 2 tabulek ti nepomuze. Spise se zamer na nastaveni indexu u sloupcu, pres ktere vybiras ci radis. Na to ti prave pomuze ten explain.

Pokud ma vetsina ulozenych uzivatelu vyplneno jen zlomek udaju (sloupcu) a predpokladas v budoucnosti pridavani dalsich sloupcu, mozna by bylo lepsi pouzit atributovou databazi (respektive navrh).


grim: a sloupecek "prava" mas jako varchar/text? Gratuluji, prisel jsi na jednu z nejvetsich prasaren co lze v SQL delat. Takhle se to proste nedela.
joe
Profil
Díky všem za příspěvky.

Dal jsem to tedy nakonec do jedné tabulky. V budoucnu možná některé další přibydou, ale není to moc pravděpodobné.

grim
Mám to tak, že mám stránku s uživatelem a pak jednotlivé záložky. Základní, kontakt, ostatní...atd. Na každé té kartě si uživatel bude moci něco vyplnit (zhruba tak 10 věcí). Většina sloupečků ja varchar.

ninja
Ještě mě napadlo, dát každou tu kartu zvlášť do jedné tabulky, pak by přidávání sloupců nebylo problém. To je ale zase to, čeho jsem se chtěl zbavit, že při upravování musím kontrolovat, jestli je tam řádek uživatele (který to upravuje). Možná by to ale bylo lepší.

S tím indexem, chápu to dobře, že mám nastavit indexy na sloupce, které používám u dotazu u WHERE.
(př. SELECT .... FROM uzivatele WHERE jmeno = '..' => Tady bych nastavil index na sloupec jmeno)

Mohl bys mi nějak prosím tě upřesnit tu atributovou databázi, hledal jsem, ale skoro vůbec nic jsem o tom nenašel.
ninja
Profil
joe: ano, s indexi jsi to pochopil dobre. Plus jeste na ty pres ktere casto seradujes data (ORDER BY), slucujes tabulky, agregujes...

Atributova databaze:

Budes mit jednu tabulku tabulku UZIVATELE, kde bude jen par veci (id + nejake systemove veci). Vedle toho mas tabulku ATRIBUTY, ktera ma struktu:
id, uzivatel_id, atribut, hodnota

a budes do ni vkladat hodnoty napriklad:

1, 1, jmeno, 'Franta'
2, 1, email, 'franta@example.com'
3, 1, narodnost, 'ceska'
4, 2, jmeno, 'Pepa'
5, 3, oblibeny_film, 'Titanic'

Tim ti kazdy uzivatel zabere jen 1 radek v UZIVATELE a n radku v ATRIBUTY podle toho, kolik udaju vyplni. Kazdy uzivatel muze mit nekonecne atributu. Jen je omezeni ze to vzdy bude stejne datovy typ (asi varchar), ale i to lze obejit.
koudi
Profil
To je ale zase to, čeho jsem se chtěl zbavit, že při upravování musím kontrolovat, jestli je tam řádek uživatele (který to upravuje).

Ne nezbytně nutně. V mysql muzes pouzit INSERT .... ON DUPLICATE KEY UPDATE ...
joe
Profil
ninja

Diky. Navedl jsi mě opět na něco, že o tom budu přemýšlet. Nevím ale, jak bych potom takové atributy vybíral. V tuto chvíli mě nenapadá jiný způsob než

SELECT hodnota WHERE (atribut = 'jmeno' OR atribut = 'email' OR atribut = 'narodnost') AND uzivatel_id = 10;

ale už vůbec nevím jak by to bylo při vkládání :) Když bude na té kartě například možnost nastavení 15 hodnot, musel bych 15 zkontrolovat jestli už řádek neexistuje, ale možná to jde udělat i lépe a pletu se.

Každopádně díky za radu.
joe
Profil
koudi

super :-) To vidím poprvé a to je přesně to, co jsem potřeboval.

Teď ještě přemýšlím...

1) jestli bych to měl nechat všechno v jedné tabulce a vybírat

SELECT * FROM atributy

a vysledek cachovat (tzn. bude jen jeden soubor)

nebo

2) vybirat postupne a cachovat. To pak bude souboru podle poctu karet u uzivatele. To znamena, ze by kazdy uzivatel mel ulozeno v cachi asi 10 souboru.

Mozna by se vyplatilo spise ta prvni varianta, aby to zbytecne nezabiralo misto a bylo vse v jednom souboru.
joe
Profil
koudi
Tak jsem se na to pouziti podival, ale cetl jsem o tom, ze je to i pomalejsi, nez napred zkontrolovat jestli neexistuje, v tom pripade insert, jinak update. Tak nevím zda to používat nebo ne.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0