Existují dvě transakce. Nejprve první transakce provádí příkaz. Poté druhá transakce provádí příkaz. Následně první transakce pokračuje. Která sekvence povede k vzájemnému zablokování? ```sql -- první transakce update accounts set balance = balance + 100 where id = ?; -- druhá transakce update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
Podíl botového provozu Tým proti podvodům vyvinul mechanismus pro detekci botového provozu na webu obchodu: když bot vstoupí na web, do parametrů jeho URL se přidá podřetězec "bot" (bez rozlišení velkých a malých písmen). Pokud byl user_id alespoň jednou v prosinci identifikován jako bot, měl by být vždy považován za bot. Prostudujte datovou sadu s návštěvami uživatelů na webu a vypočtěte podíl botů z celkového počtu uživatelů v prosinci 2024 (zaokrouhlete na jedno desetinné místo). Formát vstupu Tabulka visits: - event_date (date) — datum návštěvy - user_id (int) — unikátní identifikátor uživatele - url (string) — odkaz, přes který byla návštěva provedena Data neobsahují chybějící nebo nesprávné hodnoty. Formát výstupu Dotaz by měl vrátit tabulku s poli: - share (float) — podíl botů z celkového počtu uživatelů v prosinci, zaokrouhlený na jedno desetinné místo.
Jak obnovit práci z vzdálené větve, pokud při pokusu o `git checkout hotfix/missing-footer` obdržíte chybovou zprávu, že větev nebyla nalezena?
Jaká strategie by byla účinná pro odstranění zranitelnosti ve všech větvích s minimálním rizikem narušení chodu projektu? - Vytvoření série revert commitů pro problematický commit a všechny commity, které jej částečně opravily, poté vytvoření nového commitu s úplnou opravou - Vytvoření hotfix větve od bodu před problematickým commitem, provedení oprav a sloučení této větve se všemi postiženými větvemi - Vytvoření jednoho opravného commitu pomocí git revert abc123 na hlavní větvi a následné cherry-pick tohoto commitu do všech release větví - Použití git bisect k přesnému určení problematického kódu, vytvoření záplaty a její aplikace na všechny větve pomocí git am - Použití git rebase -i k úpravě problematického commitu v každé větvi, následované force-push (force-push)
Analýza aktivity uživatelů v reklamních kampaních Společnost vede záznam událostí souvisejících s reklamními kampaněmi. Jsou poskytnuty dvě tabulky: • campaigns — seznam reklamních kampaní s jejich identifikátory a názvy; • events — události uživatelů podle kampaní s informacemi o typu události (například 'click' (klik)) a čase. Je nutné vytvořit zprávu pro každou kampaň s následujícími ukazateli: • Celkový počet událostí. • Počet unikátních uživatelů, kteří události provedli. • Čas prvního a posledního události podle kampaně. • Pořadí kampaně podle klesajícího celkového počtu událostí. Pořadí je číslo přiřazené každému řádku ve výsledkové sadě na základě pořadí dat. Pokud mají dvě nebo více řádků stejnou hodnotu, dostanou stejnou pozici, ale následující pozice je přeskočena. Zpráva by měla obsahovat pouze kampaně, které měly události: kampaně bez událostí se nezahrnují. Finální zpráva by měla být seřazena nejdříve podle pořadí kampaně vzestupně, a poté podle campaign_name v abecedním pořadí. Formát vstupu • campaign_name (string) — název reklamní kampaně • start_date (timestamp) — datum a čas začátku kampaně • end_date (timestamp) — datum a čas konce kampaně Tabulka events: • event_id (int) — unikátní identifikátor události • user_id (int) — unikátní identifikátor uživatele, který provedl událost • campaign_id (int) — unikátní identifikátor kampaně • event_type (string) — typ události, například 'click' nebo 'conversion' • event_time (timestamp) — datum a čas události Data neobsahují chybějící nebo nesprávné hodnoty. Formát výstupu Dotaz by měl vrátit tabulku se sloupci ve správném pořadí: • campaign_name (string) — název reklamní kampaně • total_events (int) — celkový počet událostí souvisejících s kampaní • unique_users (int) — počet unikátních uživatelů, kteří provedli události • first_event_time (timestamp) — datum a čas prvního události kampaně • last_event_time (timestamp) — datum a čas posledního události kampaně • campaign_rank (int) — pořadí kampaně podle klesajícího celkového počtu událostí Seřadit data podle pořadí kampaně vzestupně, a poté podle campaign_name v abecedním pořadí.
Co je třeba udělat, pokud chcete změnit větev, na kterou odkazuje podmodul? - Podmoduly nepodporují změnu větve - Odstraňte podmodul a přidejte ho znovu s požadovanou větví - Změňte větev v podmodulu a proveďte commit v hlavním repozitáři - Spusťte git checkout na požadované větvi v podmodulu a zaznamenejte změny v hlavním repozitáři - Spusťte git submodule update --branch s uvedením nové větve
Proč zvažujete nyní pracovní nabídky?
Co se stalo a jak obnovit práci?
Tabulka notifications obsahuje pole status, jehož hodnoty jsou: 'sent', 'delivered', 'read'. Který z dotazů je správný? select * from notifications where status like '%sent%' order by created_at desc limit 5 select * from notifications where status = 'read' order by created_at desc limit 5 select * from notifications order by status desc limit 5 select * from notifications where status not in ('sent', 'delivered') order by created_at asc limit 5 select * from notifications where status in ('sent', 'delivered') order by created_at desc limit 5
Jakou operaci provedl příkaz? - Provedl git revert na commit s config.yaml - Provedl git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Provedl git rebase -i odstraněním commitů obsahujících změny souboru - Provedl git commit --amend a git push --force - Použil git cherry-pick k vytvoření nové větve bez config.yaml
Struktura tabulek uvedená na obrázku byla vytvořena. Je nutné spustit dotaz uvedený na obrázku. Jaký typ joinu je třeba použít na místě [...], aby ve výsledku byly pro záznamy s type = 'table_aw' vyplněny sloupce 'naming', a pro záznamy s type = 'table2' sloupce 'serial_number'? create table multirelation( type varchar not null, entity_id integer not null ); create table table_aw( id integer primary key, naming varchar not null ); create table table2( id integer primary key, serial_number varchar not null ); -- struktura tabulek select m.type,m.entity_id, ta.naming, t2.serial_number from multirelation m [...] join table_aw ta on m.entity_id = ta.id and m.type='table_aw' [...] join table2 t2 on m.entity_id = t2.id and m.type='table2'; -- dotaz Nechte prázdné inner cross right left
V PostgreSQL hlavička verze řádku obsahuje parametr xmax. Jakou roli hraje v řízení transakcí? - Pro vytvoření unikátního identifikátoru řádku v tabulce - Pro kontrolu viditelnosti řádku ostatními transakcemi - Pro označení čísla transakce, která řádek odstranila nebo aktualizovala - Pro zablokování řádku před současnými změnami více transakcemi - Pro určení maximální hodnoty, která může být zapsána do číselného sloupce
Prosím, řekněte nám, proč vás tato pozice zajímá.
Který příkaz z kořenového adresáře projektu by měl být použit k aktualizaci podmodulu docs/ na nejnovější verzi z vzdáleného repozitáře a k přípravě této změny k commitu? git fetch docs/ && git merge docs/FETCH_HEAD git pull --recurse-submodules git submodule update --remote docs/ cd docs/ && git pull && cd .. && git commit -am "Aktualizace" git submodule update --init docs/
Analýza návštěvnosti fitness klubů Pracujete jako analytik v síti fitness klubů. Máte informace o návštěvách uživatelů a o předplacených členstvích, která si kupují. Je třeba analyzovat efektivitu využívání členství. Pro každý typ členství vypočtěte: • celkový počet uživatelů, kteří tento typ členství využili. Zohledněte pouze unikátní user_id; • celkový počet návštěv tohoto typu členství. Zohledněte všechny návštěvy uživatelů s tímto členstvím; • podíl uživatelů tohoto typu členství v procentech z celkového počtu všech uživatelů (zaokrouhleno na jedno desetinné místo). Pro výpočet podílu uživatelů použijte poměr počtu uživatelů s tímto členstvím k celkovému počtu unikátních uživatelů. Každý uživatel může mít pouze jedno členství. Seřaďte výsledek podle typu členství abecedně. Vstupní formát Tabulka memberships: • membership_id (int) — unikátní identifikátor členství • user_id (int) — unikátní identifikátor uživatele • membership_type (text) — typ členství Tabulka visits:
Na jakých projektech v Scala jste dříve pracoval? Podělte se o konkrétní úkoly a úspěchy v této technologii.
Co se stalo a jak vrátit práci?
Co lze říci o správnosti následujícího dotazu? select * from sessions where ended_at is null and status != 'pending';
Zpráva pro logistickou společnost Jste analytikem logistické společnosti, která zaznamenává operace na skladech. Musíte sestavit zprávu o efektivitě každého skladu. Pro každý sklad vypočtěte: • celkový počet operací (count_operations); • celkový počet zpracovaných zboží na skladě (sum_quantity); • průměrnou dobu zpracování operace (avg_processing_time), pouze pro operace s určeným časem (ne NULL), zaokrouhlenou na celé číslo; • maximální a minimální počet zpracovaných zboží v jedné operaci (max_quantity, min_quantity); • počet operací každého typu («dodávka», «odeslání», «přesun») ve zvláštních sloupcích: supply_operations, shipment_operations, transfer_operations. Filtrovat sklady, jejichž celkový počet operací je větší než 2 a průměrná doba zpracování nepřesahuje 60 minut. Seřadit výsledek podle ID skladu vzestupně. Formát vstupu Tabulka operations: • operation_id (int) — unikátní identifikátor operace • warehouse_id (int) — ID skladu • operation_type (text) — typ operace: «dodávka», «odeslání», «přesun»
Máte dvě propojené tabulky: first_table a second_table. Chcete spustit příkaz TRUNCATE TABLE second_table CASCADE;, který odstraní všechny řádky z second_table a všechny závislé údaje. Jaké mohou být důsledky tohoto příkazu? create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - Sekvence second_table_id_seq bude resetována na počáteční hodnotu. - Všechny záznamy z first_table spojené cizím klíčem s second_table budou odstraněny. - Existující indexy pro second_table budou odstraněny a automaticky znovu vytvořeny. - Při následných vkladech do second_table může výchozí hodnota pro id začít nesprávnou hodnotou. - Dojde k chybě, protože příkaz CASCADE je zakázán pro tabulky s cizími klíči.
