Názor k článku Co nefunguje v MySQL a jak to obejít od Pavel Lang - PK ID vždy jen číselná forma, v opodstatněných případech...

PK ID vždy jen číselná forma, v opodstatněných případech (číselníky) se dá zkousnout i nějaký krátký varchar, ale používat všude int je pohoda pro API aplikace a pro index v DB taky. Setkal jsem se s několika způsoby generování ID, autoincrement také nemám rád a mnohdy není zapotřebí, někdy je užitečný (tak v PHP), stejně tak jako default hodnoty.

Viděl jsem dost způsobů generování ID, krom autoinkrementu také pomocí „pomocné tabulky uměle vytvořených generátorů“, což mi přišlo pro PK docela zbytečné (ale pokud to v API už je třeba pro číselnou řadu objednávek, jednoduše použitelné), precachované distribuování z aplikace (vezmu hodnotu generátoru, vynásobím konstantou a mám dost IDček, až dojdou vezmu si novou sadu), to mi přišlo docela jednoduché a s plnou kontrolou co to vlastně do DB vkládám, potkal jsem i ty nešťastné GUID, taky jsem viděl SHA1 hash jako PK, dá se toho vymyslet dost, ale stejně ja paráda, když to API umí pěkně s těma autoinkrementama. Určitě se v některých databázích a knihovnách dá doptat na následující hodnotu toho generátoru autoinkrementu, takže proč si ji tam nevložit spolu s novým řádkem autoinkrement ji snad nepřepíše, když je součástí insertu, ne?

Co jsem zahlédl někde nahoře obšívání se co když budou dvě hodnoty generované… a je k takovým „věcem“ vůbec důvod? Generovat dvě hodnoty do jednoho DB řádku mi příjde jako absolutní redundantní neužitečný nesmysl (nemluvím o calculated fields či defaults)

Mapování vložených dat na skutečně uložená jde udělat docela dobře se šikovným API a jinak defaults jsou užitečné akorát na vkládání prázdného řetězce či nuly podle typu sloupce, max ještě ten timestamp… Správný program si ale poctivě vloží stejně celou řádku jak potřebuje a na zbytek jsou DB triggery