Vlákno názorů k článku Co nefunguje v MySQL a jak to obejít od jos - mnou preferovaný řešení na defaultní hodnoty je vůbec...
-
logik (neregistrovaný)
No podle mě správný řešení jsou sekvence + triger on insert (tak se to dělá např. ve firebirdu). Pokud to v aplikaci potřebuju, tak se můžu na id zeptat předem sekvence a to pak používat (je to rozhodně lepší a rychlejší než
monstra typu guid), pokud ne, chová se to jako autoinkrement.Akorát bych bral nějakej syntaktickej curk, kterej by umoňil označit pole jako autoinkrement a vytvořil k tomu automaticky ten triger a sekvenci…
-
GUID prosím nééé, to je neštěstí. Blbě, dlouze se to zařazuje do indexu, nevíte co se tam dostane, kolikrát je PK delší než samotná data…
To už je lepší primární klíč dát jako int a ptát se na hodnotu z generátoru aplikace nebo si udělat vlastní mechanizmus, třeba si předrezervovat 100 hodnot a ty brát z aplikační cache, ale GUID je absolutně nejhorší řešení pro primární klíč s jakým jsem se kdy setkal, to ať si nechá a používá M$, naše chytré hlavičky vědí jak to udělat přinejhorším o trošku lépe, protože horších řešení už moc není. -
Filip Jirsák (neregistrovaný)
Když můžete zavolat
SELECT a, b, c FROM t1; SELECT a, b FROM t2;
a dostanete dvě sady výsledků po třech a dvou sloupcích, můžete zavolat taky
INSERT INTO t1 (a, b, c, d, e) VALUES(...); INSERT INTO t2 (a, b, c, d) VALUES(...);
a za předpokladu, že t1.a, t1.b, t1.c, t2.a a t2.b jsou automaticky generované hodnoty, dostanete strukturou stejnou sadu výsledků, jako u toho selectu. Pokud to tedy podporuje ovladač databáze, knihovna atd.
-
Filip Jirsák (neregistrovaný)
Zbytečný overhead je to pro ty, co používají databázi jako skladiště dat pro PHP a relační uspořádání dat a další věci jsou jim na obtíž. Pokud někdo naopak využívá sílu relačních databází, má v databázi nadefinované kontroly, pohledy apod., ten bude chtít mít přirozeně v databázi i výchozí hodnoty. Nemusí se pak starat o to, aby každá aplikace přistupující k databázi měla nadefinované stejné výchozí hodnoty, nemusí se v každé aplikaci pachtit s tím, jak udržovat jednoznačné primární klíče, jak udržovat data konzistentní…
-
jos (neregistrovaný)
v databázi používam mnoho fíčur, přirozenost „chtění mít defaulty v db“ je jen váš osobní názor.
pokud mam v každý aplikaci generátor guid (nejlépe v podobě vestavěný funkce), tak je o dost levnější použít guid, než se v každý aplikaci starat o mapování „vloženejch“ dat na data skutečně uložený (sekvence v pg sou taky v pohodě, protože mam na výběr jak s nima zacházim).
defaulty (neklíčovejch atributů) můžu mít někde stranou v jednom konfiguračním souboru pro všechny aplikace.
prostě nemam rád postupy (autoincrementy, defaulty, …) o kterejch vim že mi můžou nakopat zadek -
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
