Dotaz: mysql update LIMIT

[adrinko]

ahojte,

snažím sa updatnuť všetky riadky v db, kde clovek_id =1, ale vynechat prve tri takéto a updatovať až všetky ostatné. Myslel som si, že to vyrieši LIMIT 3, 18446744073709551615 ale asi sa to nedá použiť na UPDATE. ako vyriešiť toto?

Odpovědi

[Tarmaq]

to je v te tabulce 18446744073709551615 zaznamu????

[adrinko]

zatiaľ nie, to je len max hodnota unsigned bigint. použité preto, aby to prešlo všetko. aj tak to nefunguje, ani s menším číslom.

[jekub]

Pokud existuje pk (nebo jiné kritérium pro "prve tri", tak třeba

update t t1 set ...
where
(select count(*) from t t2 where t1.clovek_id=t2.clovek_id and t1.pk>t2.pk)>=3
and clovek_id=1

[adrinko]

no teda, nejak sa v tých téčkach strácam. Môj problém je takýto, skúsim to slovne vysvetliť. Mám clovek_id a datum. A teraz by som chcel updatovat všetky riadky v databáze, kde je clovek_id=38 a datum iné ako 0000-00-00 00:00:00, ale preskočiť by mal prvé tri záznamy toho človeka a updatovať všetko ostatné počínajúc štvrtým záznamom. snáď som to neschaosil :D

[l0gik]

update * where id in (select tady můžeš dát cokoli....)

jestli mysql furt nezvládá update se subselectem na stejnou tabulku, tak si ty záznamy, který chceš, nejdřív hodit do temporary table a použít v subselectu tu temporary

create temporary table bleble as select blablabal

[l0gik]

V podstatě si subselectem vybereš ty záznamy, na který se má ta operace provýst a ten subselect můžeš v pohodě limitovat.

[adrinko]

l0gik, diky, presne tento update * where id in (select .. som pred par hodinami skusal, ale asi mam starsu 5.x mysq, lebo hlaska prisla "This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'" :/

zatial som to narychlo osetril nacitanim ideciek do stringu a naslednym pouzitim update * where id in ('4','6',...). musim sa zoznamit s tymi docasnymi tabulkami, aby som to nejako zakomponoval do toho. diky moc

[adrinko]

aby som bol presny, na toto

"UPDATE table SET datum = '2011-09-12' WHERE id IN (SELECT id FROM table WHERE clovek_id=3 LIMIT 3,99999 )"

mi vracia "This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'", mysql mam vo verzii 5.5.7. hmmm

[l0gik]

No tak vytvořit temporary table s těma idčkama, který chceš měnit a pak udělat subselect na tu temporary table místo na tu originální. Holt mysql.

[kuka]

Pokud to nemusi byt jeden dotaz, tak prirozene reseni je nejprve zjistit to treti nejnovejsi datum a pak ho normalne pouzit ve where podmince.

[Toman]

Hehe, já to říkám pořád - neříkám, že toto je právě ten případ, ale opět mi to následující fakt připomnělo.

Na pohovorech, a i obecně - na dotaz, jestli uchazeč ovládá MySQL odpoví, že ano... ale jeho znalosti končí u SELECTu a děsí se nad JOINem... připomněly mne to ty tečky :)

[Josef Kufner]

Mysql nemá rádo subselecty z tabulek, které upravuješ.

[azurIt]

Pokial sa snazis robit takuto podivnost, tak ide celkom iste o nevhodny navrh struktury tabuliek. Mozes podrobne vysvetlit, preco to robis ? Preco tie 3 riadky preskakujes ?

[adrinko]

preskakujem ich preto, lebo čas od času sa môže užívateľovi upraviť limit na počet riadkov, ktoré môže vložiť do db. inými slovami, keď včera mohol vložiť 10 a dnes len tri, tak chcem nechať tri prvé a ostatných 7 zmeniť (disablovať, upraviť na iný príznak, atď). dátumy sú pri všetkých používaných 0000-00-00 00:00:00 a len pri tých disablovaných sú iné.

[azurIt]

absolutne nechapem :) preco 7 zmenit ked moze vkladat len 3 ?

[adrinko]

ono je to tak, že včera vložil (alebo niekedy inokedy) 10 záznamov (to bolo maximum, čo mohol vložiť a editovať). dnes pre toho užívateľa už chcem maximum 3. Teda nie je to nové maximum pre dnešný deň, ale nové maximum pre tohto užívateľa dokopy. takže preto by som chcel tých 7 z 10 disablovať (updatnuť) a nechať len 3. :)

[azurIt]

Prepac ale vobec nechapem, co chces urobit (preco chces nieco 'disablovat', ked to tam je uz vlozene ??). Mozno to niekto iny pochopil a pomoze ti. V kazdom pripade na to ides zle pretoze MySQL (a celkovo SQL) nie je urcene na taketo ukony.

[kuka]

SQL rozhodne je urcene na takove ukony, jako je update radku relacni databaze na zaklade ruznych kriterii. Ze by mozna potreby tazatele lepe resil odlisny datovy model je vec jina a na zaklade dostupnych informaci to nikdo nedokaze rict.

Problem tady predevsim je, ze tazatel nevysvetlil, co chce presne udelat, zda to chce/potrebuje udelat jednim dotazem nebo skriptem, jake jsou vykonnostni souvislosti (jde o stovky, miliony, milardy zaznamu?) atd. Reseni skriptem je trivialni, reseni jednim updatem treba v Oracle je mozne, zda rovnez v MySQL a v jake verzi netusim.

[azurIt]

SQL absolutne nie je urctene na ukony typu 'vynechaj prve 3 riadky' pretoze nic take ako 'prve 3 riadky' neexistuje, vsetko zavisi od zoradenia dat. Navyse SQL neumoznuje vynechavat riadky podla umiestnenia pri ich zmene, musia sa zadat pevnejsie kriteria. Podla sucasneho datoveho modelu to nie je mozne, tym padom plati to, co som napisal - dana akcia sa v SQL urobit neda pretoze SQL na taketo veci nie je urcene (logicky, keby bolo, tak sa to urobit da).

[kuka]

Tak jiste ze ty radky musi byt prvni podle nejakeho kriteria, to je zjevne. A i kdyby bylo jedno, ktere tri radky to budou, tak to je taky sveho druhu kriterium. Zadani "z deseti radku ponech libovolne tri a ostatni smaz" je take zadani a ciste technicky na nem neni nic spatneho.

Co to znamena, ze SQL "nemoznuje vynechavat radky podle umisteni"? Ze na to neni specialni syntaxe? To neni a nikdo to netvrdi. Na druhe strane nepochybne lze pomoci SQL zjistit, ktery radek je v urcitem razeni na nejakem miste, typicka uloha na cviceni z SQL je "zjistete zamestnance s druhym nejvyssim platem". Az ho zjistim, nemam pak uz problem mu plat snizit nebo zvysit. V cistem SQL toto napsat nemusi byt primocare a nektere databaze proto poskytuji rozsireni pro dotazovani podle poradi radku, na hodnoty z predchoziho/nasledujiciho radku apod., protoze to jsou typicke potreby pro analyticke vystupy.

Posledni veta je krasny dukaz kruhem

[azurIt]

Avsak tie 'rozsirenie', o ktorych pises, su uplne mimo standardu SQL a kazda DB ich riesi inak (pripadne neriesi vobec). Takze, ako som uz napisal, SQL na taketo a podobne veci nie je urcene.

[l0gik]

Prostuduj si prosím nejnovější SQL standard, věci jako WINDOW functions, klauzuli FETCH FIRST apod.

[okbob]

Dotazy typu "dej mi n-tý řádek z něčeho" by něměly modifikovat data - už z principu je nutné je řešit nad zamknutými tabulkami, případně v úrovni SERIALIZABLE - takže to nebude nic moc. Je mi jasné, že občas je to nutné - ale obyčejně to znamená nešikovně navrženou db nebo nepochopení SQL.

[PetrHL]

Místo LIMIT 3 asi myslíte OFFSET 3 . To by mělo ty první tři záznamy přeskočit.

Pokud jen tři řádky vynechat, tak bych si přečetl ID těch řádků a použil where not in (...) nebo id <> neco and id <> neco atd. Jsou to jen tři záznamy, takže by to mohlo být jedno.

[Šangala]

MySQL:
LIMIT {[offset,] row_count | row_count OFFSET offset}

Tedy …LIMIT 3, 10 nebo …LIMIT 10 OFFSET 3 je deset řádku od třetího.

[PetrHL]

Ano, samozřejmě máte pravdu. Měl jsem se první mrknout do manuálu, omlouvám se.

[Kit]

Obávám se, že LIMIT v této podobě se dá použít pouze v příkazu SELECT a nikoli UPDATE. Ovšem pomocí složeného dotazu to určitě půjde.

[Šangala]

Jo to je pravda, nějak jsem už nereagoval v duchu původního dotazu.

[poky74]

Špatný návrh. Dlouze se zamyslet nad předěláním struktury a tenhle úkon přemýstit do aplikační části, takovéhle podivnosti mohou být původcem velkých problémů.

[Kit]

Dá se souhlasit s tím, že se jedná o špatný návrh. Ovšem zatím jsme IMHO nepochopili, o co vlastně tazateli jde, takže se radí docela špatně. Podle mne by však bylo chybou logiku přemístit do aplikační části, protože MySQL podobné úkony zvládne. Jen je potřeba nejprve zjistit, jak to vlastně má fungovat, protože mně to jasné není.

[l0gik]

Proč?? Co je špatného na požadavku upravit všechny záznamy kromě tří? Že zrovna SQL je na to nešikovné? A co? Furt je to řešení na dva dotazy v MySQL a na jediný dotaz v jakékoli databázi (No Flame ), tak nechápu, proč by kvůli tomu musel psát aplikační skript, navíc zatíženej takovejma věcma, jako že se data můžou pod rukama měnit atd... (v mysql málokdo používá repeatable read).

[azurIt]

No asi preto, ze riadky, ktore chce preskocit, sa ziadnym sposobom nelisia od ostatnych. Proste chce preskocit 'prve 3', co je uz samo o sebe kravina.

[l0gik]

A i kdyby se nelišili - pokud to je v zadání, že má vybrat libovolné tři, co s tím má dělat? To chceš např. zrušit všechny loterie? Tam se taky výherci ničím neliší.

Navíc předpokládám, že se budou lišit např. časem založení, takže může říci, že třeba platné zachová tři nejstarší.

Ale i kdyby nebylo stanoveno čím se liší a jaké tři, tak nechápu "mánii programátorů" se snažit napasovat svět do předem připravenejch škatulek a když se jim tam nevedjou, tak prohlásit, že je to špatně. Programovací jazyk slouží k popisu reality, ne naopak.

[Šangala]

Aby to nebylo ode zdi ke zdi
Programovací jazyk slouží k popisu značně zjednodušené reality

[l0gik]

Spíš bych řek, že každej popis je dosti zjednodušující. I ta kvantovka je jen přibližná. Ale jinak souhlas.

[azurIt]

Precitaj si este raz jeho otazku. On nechce vybrat nahodne tri :) proste to, co chce urobit, sa v SQL urobit neda (jednoducho ma zle navrhnutu strukturu DB). Okrem toho, SQL naozaj nie je urcene na vybranie nahodnych riadkov. Programovacie jazyky sem neplet, otazka je ohladom SQL. Cital si ju vobec ?

[l0gik]

Přečet jsem si dvakrát a furt nevím kde je problém. On chce vybrat tři (nepíše jestli náhodně nebo dle nějakého kritéria, obojí SQL umí v praxi i ve standardu) a se zbytkem něco udělat. Kde je problém?

Jedinej je v mysql, že neumí dobře podotazy, takže UPDATE ... SET ... WHERE id NOT IN (SELECT .... LIMIT) neumí a proto se tazatel ptá, jak to obejít. Ostatní databáze to umí i takto triviálně. Tak fakt nechápu, kde je problém.

PS: Tedy jednoduše to jde nikoli náhodně, ale dle nějakého nedefinovaného kritéria, většinou pořadí fyzického uložení, ale to je jedno - pravej náhodnej výběr z DB je pravda trochu složitější.

[l0gik]

Navíc - SQL je programovací jazyk jako každej jinej, to, že je speciálně zaměřenej na tom nic nemění - fakt mám rád lidi, který když se někdo zeptá na konkrétní dotaz, tak ho odpálkujou, že má blbě navrženou databázi, aniž by řekli v čem a jak by to řešili jinak. - spíš mám popravdě pocit, žes jeho dotaz nečet sám. To, co chce, je naprosto standardní věc a poměrně častá (máš X slotlů na něco, následně se něco změní - např. vyprší předplatné - a sníží se ti počet slotů), tak fakt nevím, co se ti na tom nelíbí.

[azurIt]

Ok, ked si taky macher a my vsetci blbci, tak preco mu neodpovies ? :)

[azurIt]

Tu mas zhrnutie, co ten clovek potrebuje urobit: 1 2 3 4

[l0gik]

Já netvrdím, že jsi blbec (byť se mi ta replika o potrefené huse na jazyk dere ). Jen to co jsi napsal není pravda a navíc jsi to ještě napsal nepřijemně.

Navíc, řešení pro mysql jsem nahoře napsal (řešení s temporary table), kolega to doplnil s možností aplikačního řešení. Má to své problémy s izolací transakcí (bez zámků by to muselo být serializible), ale pokud ty tři vyselektované záznamy zamkne, tak to fungovat bude.

[azurIt]

Ale samozrejme, ze riesenia existuju ale to su skor 'riesenia' (v uvodzovkach), inak povedane 'kraviny, ktore obhadzaju hlavny problem - zla struktura DB'. Ak si naozaj taky expert, akym sa tu tvaris, tak fakt nechapem, ako toto mozes povazovat za riesenie. Ty by si naozaj riesil 'temporary table' na mieste, kde za normalnych podmienok patri obycajny 'WHERE' ?

[l0gik]

Znova: co je špatně na struktuře databáze a jak bys to řešil jinak?

Ano, v mysql, protože nepodporuje spoustu věcí ze standardu, se holt musí některý věci blbě obcházet. Takže bych to řešil pomocí temporary table, protože to v mysql holt jinak nejde. Nechápu, jak z toho, že mysql neumí něco, co by dle standardu umět měla vyvozuješ, že něco není úloha pro mysql.

Jelikož pořád opakuješ dokolečka to samé jako troll (termínus technikus, nikoli urážka), na další Tvé posty nebudu reagovat, dokud nenavrhneš pro daný účel lepší strukturu databáze.

[azurIt]

Z popisu naozaj nie je mozne navrnut lepsiu strukturu, pretoze sa ani neda pochopit, co presne a preco chce adrinko. Navyse ani nepozname sucasnu strukturu (ty si si ju zrejme domyslel pomocou nejakych jasnovideckych schopnosti).

[l0gik]

Pokud jsi z jeho popisu nepochopil strukturu databáze a co autor chce, je to Tvůj problém, nikoli problém tazatele. Ostatní zde v diskusi to evidentně pochopili.

Jen nechápu, jak můžeš tvrdit, že je špatná (tedy že jde udělat lepší), když nevíš, jaká je.

[l0gik]

A ještě zopakuji, aby Ti to bylo úplně jasné: ve všech ostatních db to jako podmínka do where napsat lze, je to pouze problém mysql.

[azurIt]

Fakt mam rad ludi, ktori tlacia uplne blbe riesenie len preto, ze sa to tak urobit da. Ten clovek pouziva MySQL takze je uplne irelevantne, co vedia alebo nevedia ine databazove systemy, on potrebuje riesenie pre MySQL. A jedine normalne riesenie pre jeho problem je zmenit strukturu DB tak, aby sa tam dal pouzit jednoduchy WHERE. Ale jasne, naco by sme pri radeni pouzivali mozog, ked sa to da urobit 100x zlozitejsie a narocnejsie :)

[l0gik]

Na začátku jsi tvrdil, že to je problém SQL. Když jsme Ti dokázali, že to není problém SQL, že akorát SQL neznáš, tak se začneš točit na mysql?

Proč je řešení s temporary table blbé? To je takový problém poslat na SQL server jeden dotaz navíc? Ve výsledku to ten SQL server bude řešit stejně, jako by jiný SQL server řešil anonymní tabulku z poddotazu.

Struktura dat se má řídit svojí logikou a nikoli implementačními detaily. Jelikož navrhuješ úpravu databáze jen proto, že MySQL neumí jeden kus stadardu, je to, co navrhuješ, v rozporu s tímto pravidlem. Ve výsledku to pak při vývoji způsobí více problémů, než užitku.

Danej problém vždy bude potřeba řešit v MySQL na více dotazů, nebo kdybys udržoval v databázi spešl pořadí prvků, což jsou řešení ve výsledku daleko náročnější, než jeden dotaz navíc.

[Erbureth]

IMHO by pomohlo rozdělení do tří kroků:

1) Označit řádky, které se budou zachovávat (UPDATE ... WHERE ... LIMIT 3)

2) Smazat všechno ostatní

3) zrušit to označení :)