MySQL a primary indexy

[fari]

zdravim,
rad bych znal vas nazor na to, co je v tomhle pripade lepsi reseni, co se tyce indexu a vykonosti:

Mysql, tabulka obsahuje (idDoTbl1, idDoTbl2 vchnakejTextik). Kombinace tech id je unikatni a byla by primarnim indexem. Je lespi zvolit:

• primarni index nad (idDoTbl1, idDoTbl2)
• nebo radsi pridelat sloupec idVlastni, ktery bude primarnim indexem a nad tou kombianci (idDoTbl1, idDoTbl2) pouze udelat unikatni index

jak si mysql poradi s primarnim indexem nad dvojici sloupcu? Pres tuhle tabulku se pak jinde joinuje.
Zkousel jsem neco vygooglit, ale k nicemu rozumnemu jsem zatim nedosel.
Diky

[Reklama]

[Marek Soldát]

Index nad dvojící sloupců zvládá MySQL celkem obstojně, nicméně máme celkem objektivní důvody, proč toto nepoužívat a i nad takovouto tabulkou vytvářet nový sloupec s unikátním ID, který bude jako PRIMARY.

[Kajman]

...máme celkem objektivní důvody, proč toto nepoužívat...

Prosím o upresnění důvodů. Osobně považuji pk na dvojici takových sloupců za lepší řešení.

[PCnity]

Dovod neudam, len moj postoj:

Do kazdej tabulky napchat jej vlastne ID a to dat ako primary.

[fari]

no, taky by me zajimaly ty duvody, proc ten primarni klic nad dvojici sloupcu nepouzit. Vysledek by je funkcne ekvivalentni, tak me zajima proc vybrat jednu nebo druhou volby z jinych duvodu, nez ze se mi ta ktara vic zamlouva,
zatim me jen napadlo ze ta volba PK nad dvojici usetri nejake misto (samotna data ve sloupci a index), ale misto neni uplne to co by me trapilo, spis vykon pro select nad joinem

[Reklama]

[Vlasta A]

Slozeny index funguje bez potizi v pripade, ze se take podle nej vyhledava nebo joinuje. Problem nastava napr. kdyz mame slozeny klic napr ze dvou sloupcu a provadime join pres klic druhy v poradi. V takovem pripade muze optimalizator index vyuzit, ale taky nemusi, nekdy ani hint nepomuze. Paklize joinujeme pres prvni z dvojice klicu, tak optimalizator ma vetsi vuli index pouzit, takze s ohledem na tuto skutecnost je dobre uvadet poradi polozek v klici podle dulezitosti.
Pridavat sloupec s dalsim id a ten mit jako primarni klic jenom proto, ze mam ztrach ze slozenych klicu, zejmena kdyz je slozeny pouze ze dvou hodnot, mi neprijde moc vhodne. Budes mit slozeny unique index a jeste se ti bude tvorit index nad id sloupcem. V pripade velkeho mnozstvi insertu budou dva indexy zbytecne brzdit. To uz je lepsi udelat index nad tim druhym sloupcem, paklize podle nej minim nekdy vyhledavat. Samozrejme moznost tvorby vlastni primarniho klice nezavrhuju, jen je treba mit pro to padnejsi duvody, ty ale nejak marne hledam u tabulky s primarnim klicem o dvou polich...

[Franta Kučera]

1) rozlišovat klíče a indexy. Primární klíč souvisí s logikou věci – identita záznamu. Zatímco indexy jsou technická pomůcka pro zrychlení přístupu, k nalezení daného záznamu, řazení atd. Databázový systém sice typicky vytváří index při vytvoření PK, ale není dobré tyto pojmy slučovat. Indexů si můžu vytvořit kolik chci, bez ohledu na to, jaké mám nebo nemám PK – můžu si udělat třeba index nad jedním sloupečkem, který už je součástí složeného PK.

2) V tvém případě se jedná o normální vazební tabulku → složený primární klíč je zcela na místě, neboj se ho :-)

3) Cpát automaticky do každé tabulky umělé číselné ID jako primární klíč je s prominutím hloupost. Umělým PK je lépe se vyhýbat a používat je jen když je to nutné – když neexistuje nějaký přirozený identifikátor. Případně tehdy, pokud k tomu máme nějaké vážné důvody (např. výkonnostní). Ale to není tento případ. Je dobré se zamyslet, jestli budeme někdy potřebovat adresovat konkrétní řádek na základě toho umělého ID. Budeme? Povede odněkud odkaz na toto umělé ID? Nebo naopak povedou odkazy na ty složky složeného PK? I kdybychom tam totiž to umělé ID jako primární klíč „napchali“, bude nám na nic. Všechny JOINy se budou dělat přes jiné sloupečky. Nebo když např. budeme chtít nějaký záznam smazat, budeme vědět, že chceme smazat záznam, kde a=123 AND b=456, nikoli záznam kde id=234. Takový primární klíč je zbytečný.

Tohoto zlozvyku bych doporučoval se zbavit :-) Primární klíč nemusí být jen číslo a už vůbec nemusí být tvořen jen jedním sloupečkem. A jsou dokonce i tabulky, kde primární klíč nemusí být vůbec (byť je to celkem vzácné).

4) Tohle „idDoTbl1, idDoTbl2 vchnakejTextik“ měly být názvy sloupečků, nebo je to jen nějaký příklad? Trochu mi to připomíná maďarskou notaci ;-)

[Raskal]

zdravim,
rad bych znal vas nazor na to, co je v tomhle pripade lepsi reseni, co se tyce indexu a vykonosti:

Mysql, tabulka obsahuje (idDoTbl1, idDoTbl2 vchnakejTextik). Kombinace tech id je unikatni a byla by primarnim indexem. Je lespi zvolit:

• primarni index nad (idDoTbl1, idDoTbl2)
• nebo radsi pridelat sloupec idVlastni, ktery bude primarnim indexem a nad tou kombianci (idDoTbl1, idDoTbl2) pouze udelat unikatni index

jak si mysql poradi s primarnim indexem nad dvojici sloupcu? Pres tuhle tabulku se pak jinde joinuje.
Zkousel jsem neco vygooglit, ale k nicemu rozumnemu jsem zatim nedosel.
Diky

pokud mas jen tuto tabulku a ty dve odkazovane, tak neni treba pridavat dalsi zavislosti, jejichz produkt nepouzijes - v tomto pripade umely primarni klic.

pokud ale napriklad intenzivne pouzivas dotazy na DB strukturu, kde adresujes zaznam z diskutovane tabulky jako celek, pak se primarni klic muze hodit, protoze misto 2 atomickych struktur mas jen jednu (tedy dalsi tabulky odkazujici do tve vztahove budou odkazovat jednim id misto dvema). tedy jednoducha odpoved na tvou otazku neexistuje a optimalni reseni zavisi na poctu zaznamu v tabulkach, jejich vlastnostech, zpusobu a intenzite pouziti v dotazech, na typu dotazu atd... mas-li v kazde tabulce relativne malo zaznamu a chces to udrzet relacne ciste, pak nemusis pracovat optimalne. chces-li ale prave optimalizovat pro konkretni typ dotazu, pak je potreba zadat uplnou specifikaci problemu a pak je mozne rozhodnout.

pokud je otazka skutecne polozena tak "jednoduse" jak jsi ji polozil, pak je moje odpoved: umely primarni klic nepotrebujes, tak ho nedelej.

chtel bych obhajit pravidlo "vzdy nahrazovat slozeny primarni klic umelym primarnim klicem + alternativnim klicem" a melo by mi k tomu stacit jeden prosty duvod: navrh schematu neni nikdy konecny a dochazi k jeho rozsirovani. proto je vzdy lepsi nahrazovat, protoze pote se dela mene prace jak na strane DB, tak na strane aplikace nad DB. pro opacny postup musime mit dobry duvod.

[tomk70]

3) Cpát automaticky do každé tabulky umělé číselné ID jako primární klíč je s prominutím hloupost. Umělým PK je lépe se vyhýbat a používat je jen když je to nutné – když neexistuje nějaký přirozený identifikátor.

Sice nepracuji z mySql ale toto je u všech databázi stejný princip.
Osobně jsem toho názoru že je u většiny tabulek vhodné umělé číselné ID jako primární klíč. Samozdřejmě jsou vyjímky když je to vhodné
Výhody
1. V případě nutnosti dodělat nějakou vazbu na tabulku jako číselník mám pouze jeden numerický sloupec který musím přidat jako cizí klíč.
2. Mám relativně malé indexy (rychlejší) pro primární a cizí klíče.
3. V případě změny údaje v klíčovém poli (np. vnitřní označení materiálu) nemusím mít klíče ON UPDATE CASCADE a aplikace zobrazí změněný údaj korektně.
Nevýhoda
1. Není z dceřiné tabulky hned jasno jaká hodnota tam má být. je třeba použít join. A nutnost použití join by měla být vidět z pohledu na Constraints.

[Logik]

Osobně jsem pro používání "umělejch" klíčů. Z jednoho prostýho důvodu - spousta frameworků spoléhá na existenci id, nebo i některý vlastní fce se Ti zjednodušej.

Navíc to je i rozšiřitelnější, např. nebudeš muset příliš měnit aplikaci, pokud budeš potřebovat m:n vazbu parametrizovat (a dvojice a_id, b_id nebude muset bejt už
unikátní).

Navíc existence umělýho klíče ničemu nevadí (výkon neřešim, ten minimální overhead je fakt jedni, pokud se teda nejedná oi twiter nebo podobný monstrum).

PS: A cpát do každý tabulky umělý id, i když je záznam jednoznačně identifikovaný svými daty je naopak velmi rozumné. Je proto řada důvodů, např:

- časem může dojít k tomu, že používanej "významovej identifikátor" není potřeba (a bude se odstraňovat -   může být časem případ např. rodného čísla)
- že tento identifikátor je třeba u záznamu měnit (např. username uživatelů - kvůli změně username uživatele se hned nemusí měnit záznamy v půlce db),
- časem se může změnit význam daného identifikátoru a ten tím ztratí jedinečnost
- u reálnejch významovejch identifikátorů může dojít i k duplicitě tam, kde by být neměla (např. rodné číslo)
- bude třeba ukládat do tabulky i "nedokončené záznamy" s nevyplněným identifikátorem
apod....

Naopak pro nedávání jednoznačného identifikátoru je pokud vím jen jeden důvod, a tím je o fous vyšší rychlost databáze a menší spotřeba místa, což je imho v 99.99% irelevantní - jinak ten sloupec naprosto ničemu nevadí.

[Franta Kučera]

když myslíš…

[Logik]

Velmi nedoporučuji používat "přirozené identifikátory" (jako např. rodné číslo apod.) a především/vůbec jakékoliEXTERNÍ identifikátory jako primární klíč. Důvodů je více
- možnost duplicit. Ano, neměla by být, ale prostě v praxi někdy nastane
- změna legislativy, vedoucí např. k odstranění či nahrazení identifikátoru
- složitější přečíslování v případě jeho změny (změna pohlaví apod.)
- vazba na jeden daný identifikátor a z toho plynoucí problémy, když pak se má používat ještě jiný identifikátor(např. plánovaný přechod státní správy z RČ na číslo sociálního zabezpečení, kdy budou najednou potřebaoba identifikátory)
- složitě se musí řešit případ, kdy je třeba založit entita, která má daný identifikátor neznámý, nepřidělený apod.

V případě složeného umělého identifikátoru, na který byl původní dotaz, tak silné důvody pro použití umělého klíče nejsou, ale pořád může dojít k tomu, ževazba unikátní vazba n:m je třeba předělat na parametrickou vazbu n:m, kdy přestane platit unikátnost, a tedy je univerzálnější způsob tam mít ten umělý PK. Navíc s ním různé knihovny počítají.
Důvod, proč ho nemít, je leda rychlost, a ani tam to není černobílé: pokud není na tu tabulku třeba odkazovat, je rychlejší ho nemít, pokud odkazovat třeba je, tak složený PK bude pro selecty nejspíše pomalejší. Ale to už se pohybujeme v oblasti premature optimization: obecně bych doporučil, pokud není nějaký extra silný důvod ho nemít, tak ho tam dejte.

.... aha.... chytil jsem se na spam, prosím admina smazat :-) a tak chytře jsem to napsal :-)

[kanoe22]

@Logik, je to 14rokov stare vlakno, ako sa k tomu da vobec dostat inak ako hladanim? Normalne ma to zaujma

[redustin]

Snadno - do vlákna čerstvě přispěl spambot, následně odpověděl Logik na staré vlákno, a poté admin příspěvek spambota smazal.