Diskuze: Nasledujúce ID v databáze
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.
Martin Suchodol:1.8.2020 6:35
Ahoj je to jednoduché složí k tomu tento dotaz
SELECT AUTO_INCREMENT
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = ""
AND TABLE_NAME = ""- WHERE TABLE_SCHEMA -> jméno databáze
- AND TABLE_NAME -> jméno tabulky
Výsledek pak můžeš vidět v příloze kterou přidávám
Kdyz nahravas obrazky k formulari, vlozis formular, pres lastinsert id
zjistis, jake ti priradil id a to pak pouzijes pro ukladani obrazku. Id dalsiho
zaznamu nepotrebujes, kdyz vis posledni, ne?
A jinak s tim docela bacha, pokud nepracujes v transakci a tvuj cyklus
generujici sql dotazy bude dostatecne pomaly, tak pri id+1 id+2 id+3 se muze
stat, ze mezitim jiny script v pameti dela totez a ti tam vlozi zaznam 
Cili, vzdycky jit pres
last_insert_id a idealne pres transakce, pokud navysujes id vic nez o +1.
Bugmaster:22.8.2020 23:25
Pokud jde o MySQL, tomuhle přístupu bych se vyhnul.
Proč?
Kdysi jsem ho použil. Fungovalo to krásně, dokonce snad ani nenastala žádná race-condition.
Problém nastal v momentě, kdy jsem přemigroval databázi na novou - verze 8.0
Obsah tabulky information_schema.TABLES jsou totiž jen statistický informace, které nemusí být aktuální.
Viz dokumentace dokumentace :
Columns in TABLES that represent table statistics hold cached values. The information_schema_stats_expiry system variable defines the period of time before cached table statistics expire. The default is 86400 seconds (24 hours). If there are no cached statistics or statistics have expired, statistics are retrieved from storage engines when querying table statistics columns.
Poučný je taky tenhle bug report bug report .
Ten člověk měl úplně stejný problém jako já
Obcházení pomocí nastavení hodnoty 0 do information_schema_stats_expiry bych taky nedporučoval: Bez toho nastavení ta aplikace nemusí fungovat správně. Takže si to musíš pamatovat, nebo zapsat někam do dokumentace. Pokud podobných specialit vznikne časem více, může z toho být pěkná noční můra.
Peter Mlich:24.8.2020 8:03
Jasne, ale nevim, zda si rozumime.
- INSERT -> LAST_INSERT_ID - to vetsinou je ok, cas mezi insertem a byva maly
- INSERT -> LAST_INSERT_ID -> INSERT id+1, INSERT id+2, INSERT id+3 - ukladas seriri dalsich insertu a davas jim id+1 id+2. Pokud ten cyklus budes mit dostatecne pomaly a v pameti jiny uzivatel spusti nad stejnou tabulkou take INSERT, muze se stat, ze treba tve id+2 se prekryje s druhym uzivatelem, jeho INSERT/LAST_INSERT_ID a vysledkem je, ze bud jeho zaznam prepises nebo ti program zkolabuje na erroru, ze takove id uz v db existuje. Jakoze, kdyz je 200 uzivatelu online, tak bezi 200 php kodu v nahodilem poradi, jak rychle a nahodile uzivatele klikaji. A kdyz se sejdou 2 takove programy... Db umi prijmout vice INSERTU od ruznych uzivatelu. Ale v transakci se vsechno od jednoho uzivatele provede jako jeden celek
[b] lze vyresit transakcemi a nebo idealne neco takoveho vubec nedelat. Treba
bys mu poradil neco lepsiho, kdyby popsal problem konkretneji, na prikldu, proc
zrovna toto potrebuje
Zobrazeno 11 zpráv z 11.