Volba primárního klíče

[JamesCZ]

Dneska jsem se s jedním známým neshodl na téma volby primárního klíče, konkrétně u tohoto příkladu:

Mám tabulku uživatelů:

login ( varchar(6) )
jmeno ( varchar(20) )
prijmeni ( varchar(20) )


Já říkám použít jako primární klíč atribut login, stejně má být jedinečný, čili proč ne.

On říká že je lepší zavést umělý klíč id a ten označit za primární.

Já si myslím, že díky umělému klíči utrpí kvalita DB a jeho normální forma, která spadne na 2NF pokud se nepletu ( aby byla 3 NF, tak nesmí existovat závislost mezi sekundárními atributy, což existuje protože pomocí sekundárního atributu (v případě že za primární klíč označíme ID) login můžeme zjistit všechny další atributy - i ten primární )

Mám na mysli MySQL.

Jaký je Váš názor?
Díky

[Aigor]

Já jsem pro ID. Nejsem teoretik, takže to neposuzuju z hlediska NF, ale čistě logicky mi práce s INT přijde rychlejší a přímočarejší než vyhledávání mezi VARCHAR položkami.
Celá léta používám prakticky všude umělé PK a nikdy jsem neměl pocit, že je to špatně - resp. že jinou možností bych něco získal.

[NeMeM9aA]

Tak ona ta rychlost prace bude zhruba stejna. Stejne se bude overovat unikatnost loginu a bude ho potreba indexovat.
Z ciste akademickeho hlediska nebude umely PK potreba ale coje podstatne, je prave to, ze proste pouzivas umele PK vsude a nemusis o tom premyslet. To znamena potom rychlejsi vyvoj a lepsi udrzovatelnost a to je to hlavni.

Takze dle moho nazoru je akademicky spravnejsi mit jako PK login ale z praktickeho hlediska bude lepsi umele ID. (lepsi prehlednost)

[frelichl]

Tabulka kde bude umělé id společně s unikátním username nebude ve 3. NF. Když se budeš někdy prohrabávat v tabulkách, kde se používá cizí klíč z této tabulky tak budeš vědět prd a budeš si muset tabulky spojovat, abys viděl kdo udělal tuhle změnu etc. Otázku rychlosti bych u aplikací menších než obrovských zanedbal.

Podle mě na tuto otázku neexistuje vyloženě správná nebo špatná odpověď, teoreticky je určitě správnější nepřidávat id zbytečně, v praxi se to tak dělá nejenom z nevědomosti, ale i kvůli tomu, že by časem někoho mohlo napadnout, že je potřeba mít možnost měnit username a v ten moment budeš za umělá id zatraceně rád.

[JamesCZ]

....v praxi se to tak dělá nejenom z nevědomosti, ale i kvůli tomu, že by časem někoho mohlo napadnout, že je potřeba mít možnost měnit username a v ten moment budeš za umělá id zatraceně rád.

Nejdříve Vám všem děkuji, především frelichl, který potvrdil to, co jsem si myslel.

Nyní k tomu výše citovanému - změnu loginu by měli nejméně u MySQL řešit právě akce ON Updates a ON delete, pokud se nepletu (je možné že jo, nevidím do toho moc).

V nejhorším není problém vytvořit atribut alias a ten zobrazovat coby login (IMHO to tak u některý fór například je, alias změníte, ale přihlašujete se stále pod loginem, ač uživatelé u Vás vidí alias).

[Zdenek Dubnicky]

Ehm...a dokážeš si představit login jako cizí klíč v jiné tabulce? To by přeci byl nesmysl, joinovat tabulky na základě stringu.
Takže rozhodně int.

[frelichl]

Na ON UPDATE CASCADE zapomínám, protože ho třeba Oracle Database neumí. Každopádně to opět ukazuje na fakt, že ať vezmeš kteroukoliv variantu, vždycky se to nějak dá ohnout a ani jedno řešení není tedy blbě. Za sebe se přikláním k podle mě čistějšímu řešení bez zbytečných id.

[frelichl]

Ehm...a dokážeš si představit login jako cizí klíč v jiné tabulce? To by přeci byl nesmysl, joinovat tabulky na základě stringu.
Takže rozhodně int.

Hej dokážu, naprosto s přehledem a ujišťuju tě, že se to tak často dělá. Heslo databázistů teoretiků je "udělej to správně a nechej databázovej stroj, ať se s tím popere".

[Zdenek Dubnicky]

Hej dokážu, naprosto s přehledem a ujišťuju tě, že se to tak často dělá. Heslo databázistů teoretiků je "udělej to správně a nechej databázovej stroj, ať se s tím popere".

Pracuji s DB až o velikosti několik GB a nemyslím, že by to bylo vhodné řešení. Ale proti gustu...

A co se týče výkonostního srovnání a dalších výhod/nevýhod - toho je v google dost, takže předpokládám, že jste již četli.

[JamesCZ]

Hej dokážu, naprosto s přehledem a ujišťuju tě, že se to tak často dělá. Heslo databázistů teoretiků je "udělej to správně a nechej databázovej stroj, ať se s tím popere".

Já to taky běžně používám ( používám MySQL )

[Zdenek Dubnicky]

Já to taky běžně používám ( používám MySQL )

Ano, určitě to lze použít, a určitě se najdou situace, kdy je to vhodné. Jen nemyslím, že by to zrovna byl tento případ. A otázka je, jestli to v konečném řešení bude vůbec hrát roli.

[Rainbow]

Rada z praxe: vzdy davat ID, pokial nie je specialny dovod na to, aby tam nebolo. Specialny dovod je napriklad tabulka unikatnych kodov s milionami riadkov. Tam sa priamo nuka pouzit kod ako primarny kluc a kazdy dalsi udaj je zbytocna zataz.

[peshwood]

Jinak tem dvema typum primarnich klicu se rika natural (login) a surrogate (id) keys. Na netu jsou tuny diskuzi, kde se to resi a "spravna" odpoved na to fakt neni. Ale osobne jsem pro surrogates.
Slusny je treba tohle:
http://www.agiledata.org/essays/keys.html

Fundamentally, there is no clear answer as to whether or not you should prefer natural keys over surrogate keys, regardless of what the zealots on either side of this religious argument may claim, and that your best strategy is be prepared to apply one strategy or the other whenever it makes sense.

[Anduril]

Jsem za umely klic, id, v praxi se nam stale ukazuje, ze to je nejlepsi reseni, i kdyz z hlediska teorie nemusi byt nejcistejsi. U nejake male db by nemusel byt problem ani ten login, ale v pripade vetsich db je to jen zadelavani si na problemy, v pripade slozenych klicu ani nemluve.

[mike.pr]

Odpověď je asi taková:

pokud nebudeš mít login > 5-10 znaků, pak to není problém, porovnává se přinejhorším 40 Byte (UTF32) přinejlepším 10 Byte (EASCII).

Je to sice dvojnásobek oproti INT (většinou 4B), ale ještě se to "dá". Výkonnostně je to už znát.

Asi víš kolik kroků je potřeba k vyhledání hodnoty v BTREE, tak asi víš ke kolika porovnání dojde.

V menších systémech můžeš dělat téměř jakékoliv prasárny, výkon počítačů se stále zvyšuje a moderní DB stroje jsou proti všem pozůstatkům z DOSu už někde jinde.

PS:
Osobně používám umělé klíče, často existují důvody proč nejsou vhodné. Častý byl zapamatovatelnost pro uživatele (z kódu pak bylo znát vždy o co se zhruba jedná FA001 je faktura).
Tyhle klíče se je člověk snaží držet co nejkratší ideálně právě do 10 znaků a ne v UTF, ale pouze v nějakém EASCII kódování.
Samozřejmě jsou často na nějakém základě generovány (např č. faktury), ale to už je jiná kapitola nazývající se číselné řady.

Moje zdroje:
Pár let praxe +
Pokorný, J.: Konstrukce databázových systémů. Skripta, Vydavatelství ČVUT, 2. vydání, 2004, 166 p.

[Marty]

Ano, určitě to lze použít, a určitě se najdou situace, kdy je to vhodné. Jen nemyslím, že by to zrovna byl tento případ. A otázka je, jestli to v konečném řešení bude vůbec hrát roli.

Pracuji s více systémy, kde se takhle s PK pracuje, nevidím v tom problém... (a nejsou to malé systémy)
Jen umělý klíč aka ID je podle mě lepší na údržbu - viz zmíněné kaskády updatů.