Volba primárního klíče

[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]

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.

[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ů.

[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.