PRIMARY KEY a INDEX

Primární klíč může být skutečně jen jeden, ale může být na více sloupcích jako v příkladu (tedy kombinace použitých sloupců musí být v tabulce vždy jedinečná).

Indexů může být více (ty také mohou být i vícesloupcové) a používají se, protože mohou pomoci při optimalizaci dotazů.

http://www.linuxsoft.cz/article.php?id_article=912

Primární klíč je primární klíč a index je index... u tabulky může být více primárních klíču (myšleno více sloupců pod jedním) a unikátnost je pak brána podle všech primárních sloupců dohromady (podle jejich unikátních kombinací). Primární k. by měly být použity pouze pro sloupce které jsou přímo spojeny s identifikací daného řádku v databázi.

ja.cz:
U primárneho kľúča automaticky vzniká jedinečný (unikátny) index.

ja.cz:
Primárny index je v ukážke pre trojicu stĺpcov, čo znamená, že sa vo všeobecnosti použije, ak sú známe hodnoty všetkých troch stĺpcov.
Teda ak je zadaná hodnota len napríklad type_id stĺpca, a zvyšné stĺpce zadané nie sú, tak sa nevyužije.
Niekde som čítal, že by mal byť taký index v MySql využiteľný pre n-tice: (`id`), (`id`,`type_id`), (`id`,`type_id`,`home_id`).
No neviem, nakoľko to je isté. A ak aj áno, tak je možno ten extra index rýchlejší.
A ten extra index je tuším nutný pre AUTO_INCREMENT.

ja.cz:
proč je v ukázce použit INDEX i PRIMARY KEY na sloupec `id`

To se zeptejte autora ukázky, my tam smysl nevydumáme.

Pro filtrování pomocí id lze použít složený primární klíč, protože id v definici úplně vlevo. Index by měl větší smysl, kdyby byl na type_id a někdy se hledalo podle tohoto sloupce bez použití id. Nebo obdobně na dalších sloupcích.

ja.cz:
„Na linuxsoft.cz je jeden z indexů označený jako jedinečný klíč. Jedná se o UNIQUE KEY“?
Áno. Jedinečný = unikátny: v tabuľke nebude možné v tom stĺpci vytvoriť dve rovnaké hodnoty. Každý riadok bude mať v tom stĺpci inú hodnotu.

„Myslel jsem si, že UNIQUE KEY nevytváří index tabulky“
PRIMARY KEY je zároveň aj UNIQUE KEY a vždy sa pritom zároveň vytvorí aj index - pri oboch týchto kľúčoch.
Indexy sú užitočné okrem vyhľadávania aj pri zoraďovaní výsledných záznamov.

Ahoj,

ten článek jsem psal já. Jenom rekapitulace toho, co tě asi zajímá:

1. Na některých sloupcích se vytváří index, pro PK sloupec se index vytváří automaticky. Index je tam z důvodu, aby se záznamy dalo podle této hodnoty rychle vyhledávat. Jedná se o index typu B-tree = neni pro fulltextové vyhledávání.

2. PK může být na více sloupcích. Jedná se jen o ukázku toho, že záznam v tabulce může být identifikován více než jedním sloupcem, pokud je pro to dobrý důvod. Daty by teoreticky stačil pro PK jen sloupec ID. Já jsem ale chtěl jít dál: řekl jsem si, že budu chtít identifikovat psa v útulku podle toho, kde je ten pes "ubytován" a případně co je to za rasu = typ. Mám tedy type_id a home_id a chci identifikovat v DB psa. Tento dotaz mi vybere možná několik psů a dle dalších popisů a vlastností vyberu toho správného. = Přijdu na jeho ID, které ten pes samozřejmě nikde na sobě napsané nemá. A tím PK na 3 sloupcích si vynutím to, že když budu psát poznámku k psovi, tak u toho musím také zadat jeho typ a ID ubytování. To je něco jako prevence proti chybám.

Jednalo se o případ, kdy ta klientská aplikace je hloupá, tak aby se zamezilo aspoň nějakým chybám ze strany DB. Od toho tam právě jsou ty uložené procedury. V ideálním případě by samozřejmě ta klientská aplikace měla být chytrá a pak si půlku funkcí u té DB můžeme odmyslet, protože prostě nebudou potřeba. V rámci toho článku jsem jasně říkal, že věci jako uložené procedury by se moc používat neměly, protože by se to mělo rozumně řešit na straně aplikace a ne až na straně DB, kde ty možnosti kontroly dat jsou už podstatně menší.

Martin