Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
24.10.2005 19:55
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
MySQL má svou oblast, kde je doma a která jí sedí. Tam zaslouženě kraluje, o tom není sporu. Není mi moc jasné, proč se za každou cenu snaží tuto oblast opustit a vrhnout se jinam, nota bene někam, kde je už dávno přecpáno.
.
U male Sybasky je nyni zajimava moznost vyuzivat ji legalne zdarma s omezenim 1 procesor, 2 GiB RAM a 5 GiB velikost DB, coz leckde bohate staci. Jenom marketingovy sum, ze skripty jsou kompatibilni s MS SQL bohuzel neni pravda - byl snaha, kde to jde, premigrovat z MS SQL prave na Sybase Anywhere, ale jednoduse to bohuzel nejde 
No a DB2 na vlastnim zeleze (iSeries, Blade center, atd.) to je mnam 
musim souhlasit a bude me velmi mrzet, jestli se z MySQL stane velka rozezrana potvora, ktera bude vhodna na vse mozne, jenom ne na amaterske bastleni ...
nejak jsem nepochopil, proc se vsichni furt maji potrebu srovnavat, proc se nedrzi toho, v cem jsou oproti konkurenci lepsi ... takovy prikladek, pred nejakou dobou (v casech MySQL 3) jsem cosi bastlil, musel jsem pouzit PostgreSQL, o kterem se mnozi hadaji do krve, ze je lepsi, ale nejake featury jako triggery a janevimco, co tehdy MySQL neumela, me vubec nezajimaly, potreboval jsem naprosto trivialni veci - jako napr. last insert id, coz jsem zjistil, ze PostgreSQL nezna (tehdy neznala?), takze jsem to musel slozite obchazet - pro me tedy tehdy v tom projektu byla PostgreSQL jasne horsi, protoze narozdil od MySQL neumela to, co bych potreboval ...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czSQL znamenaji, než se pustíte do vývoje.
Pokud chcete, aby byl sloupec unikátní, jednoduše přidáte UNIQUE CONSTRAINT, pokud se jedná o id, tak rovnou PRIMARY KEY.
V praxi se sekvence používají tak, že buď je použijete jako defaultní hodnotu pro sloupec, jehož hodnota má narůstat, nebo si z nich vyberete před vložením nového řádku novou hodnotu (která je samozřejmě pokaždé unikatní.
Takto je to zcela v duchu SQL a nepotřebujete volat nějakou obskurní funkci. Má to také spoustu výhod:
Asi byste si měl opravdu nekdřív zjistit, co sekvence v SQL znamenaji, než se pustíte do vývoje.
nebylo by od věci hodit odkaz, žádnou tlustou knihu o SQL (po ruce) nemám, prvních 10 stránek odkazů z Jyxa je na nic, Google taky nicmoc ... no našel jsem si aspoň něco o syntaxi ...
btw, "než se pustím do vývoje" - když potřebuju rychle zbastlit pár kilo kódu, nebudu kvůli tomu kupovat a číst tlustou knihu o SQL - a když nepřečtu tlustou knihu o SQL, tak se o existenci sekvencí ani nedozvím (nebýt ábíčka ), takže nemohu zjišťovat, "co sekvence v SQL znamenaji"
Pokud chcete, aby byl sloupec unikátní, jednoduše přidátejistěže PRIMARY KEY - a proto dojde k chybě, když vkládám řádek se stejným id ...UNIQUE CONSTRAINT, pokud se jedná o id, tak rovnouPRIMARY KEY.
V praxi se sekvence používají tak, že buď je použijete jako defaultní hodnotu pro sloupec, jehož hodnota má narůstat,což je akorát složitější zápis toho, co dosáhnu auto-incrementem ...
nebo si z nich vyberete před vložením nového řádku novou hodnotu (která je samozřejmě pokaždé unikatní.a jak dosáhnu té unikátnosti? - když se zeptám
SELECT sekvence.NEXTVAL FROM tabulka dvakrát po sobě (aniž by se mezitím něco vložilo či jinak manipulovalo s hodnotou sekvence), tak snad dostanu stejné číslo, ne?
... a tím pádem jsem tam, kde jsem byl v příkladu výše
Takto je to zcela v duchu SQL a nepotřebujete volat nějakou obskurní funkci.
a to jako s tím strašidlem rozmlouváte každý úplněk o půlnoci za strašidelného svitu monitoru a ono Vám ve svém zjevení řeklo, že auto_increment je špatný, je špatný, je opravdu špatný, nebo máte ještě nějaký jiný důvod, proč se drbat levou rukou za pravým uchem a říkat, že škrábání pravou rukou je obskurní?
ruku na srdce - kolik jste viděl projektů nad MySQL, u kterých by někdy nějaká migrace na jiný engine hrozila, notabene když jsou zbastleny v phpku a visí přímo na mod_mysql a ne na obecné db vrstvě? - viz výše, můj příklad se týkal vhodnosti konkrétní databáze pro konkrétní věc, kdyby šlo o něco obecného, tak neřeknu
- jedná se standard, takže nebudete mít při přechodu na jinou rdbm
to snad mohu s tím autoincrementem taky ... (nehledě na to, že mě nenapadá důvod mít v tabulce duplicitní sloupce ...)
- můžete jednu sekvenci používat na víc sloupcích i s různých tabulek
WTF? co je na LAST_INSERT_ID() nepohodlného oproti sekvence.CURRVAL ap.?
- pohodlná manipulace pomocí SQL příkazů
zajímal by mě konkrétní příklad kdy, nějak si ho neumím představit (a po výše uvedené zkušenosti s vyhledávači už jsem líný vůbec pokoušet se něco hledat, když mě ani v nejmenším nenapadá, jak sestavit frázi vedoucí k výsledku)?
- někdy se hodí znát id řádku ještě před samotným vložením řádku
btw, "než se pustím do vývoje" - když potřebuju rychle zbastlit pár kilo kódu, nebudu kvůli tomu kupovat a číst tlustou knihu o SQL - a když nepřečtu tlustou knihu o SQL, tak se o existenci sekvencí ani nedozvím (nebýt ábíčkaSQLznamenaji"
BTW. Když si sám chcete vybagrovat díru, potřebujete nejen bagr, ale také se jej naučit obsluhovat. Proč by to u databází mělo být jinak?
BTW. Když si sám chcete vybagrovat díru, potřebujete nejen bagr, ale také se jej naučit obsluhovat. Proč by to u databází mělo být jinak?když chci vykopat díru na zasazení stromku, stačí mi rýč či vhodná lopata a k obsluze potřebuji minimum znalostí ... proč by to mělo být u databází jinak? opravdu si všichni vrabci zaslouží být stříleni kanónem?
A jste si jist, že jste si v tomto případě vybral správnou ráži? Vy jste nesáhl po zmíněném rýči, ale po bagru.
serial (příp. bigserial)
a jak dosáhnu té unikátnosti? - když se zeptám SELECT sekvence.NEXTVAL FROM tabulka dvakrát po sobě (aniž by se mezitím něco vložilo či jinak manipulovalo s hodnotou sekvence), tak snad dostanu stejné číslo, ne?Do Google zadám postgres sequence a hned třeba první odkaz na pochopení bohatě stačí.fajn, a to že tam mám zadat "postgres" a ne třeba "SQL", "ANSI SQL" apod. se dozvím Božím vnuknutím nebo jak? mimochodem, popis se trošku liší od toho co jsem našel, např. hodnotu currval jsem pochopil jako poslední užitou hodnotu, nikoliv jako hodnotu vrácenou v posledním volání nextval ("currval - Return the value most recently obtained by nextval for this sequence in the current session.") ... jak se tedy dozvím, jaké je poslední přidělené id (když se nezeptám předem na nextval a nevkládám to včetně id, nýbrž id nevyplňuju a vkládám to stejným stylem jako autoincrement)?
... Ne, dostanete samozřejmě pokaždé jiné číslo, právě proto je to sekvence.to nebylo ze stránky, co jsem četl, zřejmé, viz výše
přečetl jsem ten blogpost dvakrát a stále nechápu, jak to souvisí s tím, co říkám ... autor blogpostu se zřejmě potřebuje podrbat za levým uchem a zkouší to nohama - no, já mu to neberu, ale ptám se původně, co je špatného na tom, abych se za pravým uchem drbal pravou rukou, a jak to souvisí se spiritistickými seancemi?a to jako s tím strašidlem rozmlouváte každý úplněk o půlnoci za strašidelného svitu monitoru a ono Vám ve svém zjevení řeklo, že auto_increment je špatný, je špatný, je opravdu špatný, nebo máte ještě nějaký jiný důvod, proč se drbat levou rukou za pravým uchem a říkat, že škrábání pravou rukou je obskurní?Namátkou: Gavin's Blog
Jak třeba pomocí auto_increment uděláte, aby se inkrementovaná hodnota použila ve více tabulkách zároveň?reversně k tomu, jak bych to udělal se sekvencí ... uložím do jedné tabulky řádek s auto_increment, zeptám se na last_insert_id, uložím s tímto id řádky v ostatních tabulkách ... neříkám, že by to takhle nebylo nešikovné (asi to půjde i jednodušeji), ale tvrdit, že by to nešlo vůbec není fair
A teď na začátek:v pořádku - jsem rád, že jsem se o SQL zas něco dozvěděl (rozhodně to budu mít v paměti živěji než příklad načtený z tlusté knihy o SQL, který zapomenu než ho stihnu uplatnit) nicméně nicmoc to nemění na tom, co jsem chtěl říci - MySQL mi prostě nabízela jednoduchý nástroj, jak docílit efektu, který jsem potřeboval, zatímco u PostgreSQL jsem to musel dělat složitěji (po zkušenostech z této diskuse bych to napsal jednodušeji než tehdy, ale pořád složitěji než s možností použít last_insert_id), takže z uživatelského hlediska ke mě byla (a je) MySQL prostě přítulnější ......potreboval jsem naprosto trivialni veci - jako napr. last insert id, coz jsem zjistil, ze PostgreSQL nezna (tehdy neznala?), takze jsem to musel slozite obchazet - pro me tedy tehdy v tom projektu byla PostgreSQL jasne horsi, protoze narozdil od MySQL neumela to, co bych potreboval ...Tohle jste tvrdil, a proto tento thread vznikl. Ne proto, že bych si myslel něco špatného o MySQL.
As AUTO_INCREMENT is implemented as SELECT MAX(col) FROM table, it makes transactions prone to deadlocks: http://www.mysql.com/doc/en/InnoDB_auto-increment_column.htmljestli se deadlockem míní to, co si myslím, pak nechápu, jak na to autor toho postu přišel, že je na ně MySQL náchylná ...?
Tiskni
Sdílej:
