Կան երկու գործարքներ։ Առաջինը կատարում է հրամանը։ Հետո, երկրորդը կատարում է հրամանը։ Դրանից հետո առաջինը շարունակում է։ Որ հաջորդականությունը կհանգեցնի փոխադարձ փակման? ```sql -- առաջին գործարք update accounts set balance = balance + 100 where id = ?; -- երկրորդ գործարք update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
Բոտերի տրաֆիկի մասնաբաժինը Անվտանգության թիմը մշակել է մեխանիզմ՝ բոտերի տրաֆիկը հայտնաբերելու համար՝ խանութի կայքում։ Երբ բոտը մուտք է գործում կայք, նրա URL պարամետրերին ավելացվում է «bot» ենթատեքստը (մեծատառ-փոքրատառ տարբերություն չհաշվառելով): Եթե user_id-ը առնվազն մեկ անգամ դեկտեմբերի ընթացքում ճանաչվել է որպես բոտ, ապա միշտ պետք է դիտարկել որպես բոտ: Ստուգեք օգտվողների այցերի տվյալների հավաքածուն և հաշվեք բոտերի մասնաբաժինը ընդհանուր օգտվողների թվից դեկտեմբերի 2024-ին (վերահասեք մեկ տասնորդական տեղով): Մուտքային ձևաչափ Տվյալների աղյուսակ visits: - event_date (date) — այցի ամսաթիվ - user_id (int) — եզակի օգտվողի նույնականացուցիչ - url (string) — հղում, որով կատարվել է այցը Տվյալները չեն պարունակում բացթողումներ կամ սխալ արժեքներ: Ելքային ձևաչափ Հարցումը պետք է վերադարձնի աղյուսակ՝ հետևյալ դաշտերով՝ - share (float) — դեկտեմբերի ընդհանուր օգտվողների թվին համեմատ բոտերի մասնաբաժինը, մեկ տասնորդական տեղով վերահասված։
Ինչպես վերականգնել հեռավոր ճյուղից աշխատանքը, եթե փորձելիս `git checkout hotfix/missing-footer` ստանում եք սխալի հաղորդագրություն, որ ճյուղը չի գտնվել?
Որ ռազմավարությունը կլինի արդյունավետ բոլոր ճյուղերում անվտանգության թերությունը վերացնելու համար՝ նվազագույն ռիսկով նախագծի աշխատանքը խանգարելու համար? - Ստեղծել revert-կոմիտների շարք խնդիրային կոմիտին և բոլոր այն կոմիտիները, որոնք մասամբ այն ուղղել են, ապա ստեղծել լրիվ ուղղում ունեցող նոր կոմիտե - Ստեղծել hotfix-մասա այն կետից, որտեղից սկսվել է խնդիրային կոմիտեն, կատարել ուղղումներ և միացնել այս մասան բոլոր ազդեցության տակ գտնվող ճյուղերի հետ - Ստեղծել միակ ուղղող կոմիտե՝ օգտագործելով git revert abc123 հիմնական ճյուղում և հետո cherry-pick անել այս կոմիտեն բոլոր թողարկման ճյուղերին - Օգտագործել git bisect՝ ճշտելու համար խնդիրային կոդը, ստեղծել պաչ և կիրառել այն բոլոր ճյուղերին՝ git am-ի միջոցով - Օգտագործել git rebase -i՝ խնդիրային կոմիտեն խմբագրելու համար յուրաքանչյուր ճյուղում, ապա force-push (force-push) կատարել
Օգտագործողների ակտիվության վերլուծություն գովազդային արշավներում Ընկերությունը վարում է գովազդային արշավների հետ կապված իրադարձությունների հաշվառում։ Մուտքային աղյուսակները՝ • campaigns — գովազդային արշավների ցանկ՝ նրանց նույնականացուցիչներով և անվանումներով; • events — օգտագործողների իրադարձություններ արշավների վերաբերյալ՝ իրադարձության տեսակի (օրինակ՝ 'click' (կլիկ գովազդի վրա)) և ժամանակի մասին տեղեկություններով։ Անհրաժեշտ է կազմել հաշվետվություն յուրաքանչյուր գովազդային արշավի համար՝ հետևյալ ցուցանիշներով՝ • Ընդհանուր իրադարձությունների քանակը։ • Միայն այն օգտագործողների քանակը, ովքեր կատարել են իրադարձություններ։ • Արշավի առաջին և վերջին իրադարձության ժամանակը։ • Արշավի ընդհանուր իրադարձությունների քանակով նվազման կարգով։ Ռանգը — թիվ, որը նշանակվում է յուրաքանչյուր տողի՝ տվյալների տրված կարգի հիման վրա։ Եթե երկու կամ ավելի տողեր ունեն նույն արժեքը, նրանց տրամադրվում է նույն ռանգը, բայց հաջորդ ռանգը բացակայում է։ Ներառել միայն այն արշավները, որոնց ունեցել են իրադարձություններ՝ առանց իրադարձությունների արշավները հաշվի չեն առնվում։ Վերջնական հաշվետվությունը պետք է նախ դասավորել ռանգով աճման կարգով, ապա՝ campaign_name-ի ըստ ալֆաբետային կարգի։ Մուտքային ձևաչափ • campaign_name (string) — գովազդային արշավի անվանում • start_date (timestamp) — գովազդային արշավի մեկնարկի ժամանակը • end_date (timestamp) — ավարտի ժամանակը Իրադարձությունների աղյուսակը՝ • event_id (int) — իրադարձության եզակի նույնականացուցիչ • user_id (int) — օգտագործողի եզակի նույնականացուցիչ, ով կատարել է իրադարձությունը • campaign_id (int) — գովազդային արշավի եզակի նույնականացուցիչ • event_type (string) — իրադարձության տեսակը, օրինակ՝ 'click' (կլիկ) կամ 'conversion' (փոխանցում՝ հաջողված գործողություն, օրինակ՝ գնում) • event_time (timestamp) — իրադարձության կատարման ժամանակը Տվյալները չեն պարունակում բացթողումներ կամ սխալ արժեքներ։ Ելքային ձևաչափ Հարցը պետք է վերադարձնի աղյուսակ՝ հետևյալ դաշտերով՝ • campaign_name (string) — գովազդային արշավի անվանում • total_events (int) — ընդհանուր իրադարձությունների քանակը • unique_users (int) — եզակի օգտագործողների քանակը, ովքեր կատարել են իրադարձություններ • first_event_time (timestamp) — առաջին իրադարձության ժամանակը • last_event_time (timestamp) — վերջին իրադարձության ժամանակը • campaign_rank (int) — արշավի ռանգը ընդհանուր իրադարձությունների քանակով նվազման կարգով Տվյալները դասավորել ռանգով աճման կարգով, ապա՝ campaign_name-ի ըստ ալֆաբետային կարգի։
Եթե դուք ցանկանում եք փոխել ճյուղը, որը ցույց է տալիս ենթամոդուլը, ինչ պետք է անել? - Սուբմոդուլները չեն աջակցում ճյուղերի փոփոխությանը - Ջնջել ենթամոդուլը և ավելացնել այն նորից ցանկալի ճյուղով - Փոխել ճյուղը ենթամոդուլում և կատարել կոմիտ հիմնական ռեպոզիտորիայում - Գործարկել git checkout ցանկալի ճյուղում ենթամոդուլում և գրանցել փոփոխությունները հիմնական ռեպոզիտորիայում - Գործարկել git submodule update --branch և նշեք նոր ճյուղը
Ինչու եք հիմա աշխատանքային առաջարկները դիտարկում?
Ի՞նչ տեղի ունեցավ և ինչպես վերականգնել աշխատանքը։
notifications jadvali status maydoni mavjud bo'lib, uning qiymatlari: 'sent', 'delivered', 'read'. Qaysi so'rov to'g'ri? 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
Ինչ գործողություն է կատարել команда? - Գործարկել է git revert՝ config.yaml պարունակող commit-ի վրա - Գործարկել է git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Գործարկել է git rebase -i՝ հեռացնելու համար փոփոխություններ պարունակող commit-ները - Գործարկել է git commit --amend և git push --force - Օգտագործել է git cherry-pick՝ նոր ճյուղ ստեղծելու համար առանց config.yaml
Նկարում ցույց տրված աղյուսակների կառուցվածքը ստեղծվել է։ Պետք է կատարել նկարի մեջ նշված հարցումը։ Որո՞նք են [...]-ի փոխարեն օգտագործելի join տեսակը, որպեսզի արդյունքում type = 'table_aw' համար լրացվի 'naming' սյունակը, իսկ type = 'table2' համար՝ '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 ); -- աղյուսակների կառուցվածք 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'; -- հարցում Դուրս թողեք դատարկ inner cross right left
Խնդրում ենք, պատմեք, թե ինչու եք հետաքրքրված այս պաշտոնով։
Նա PostgreSQL-ում, տողային տարբերակի գլխում ընդգրկված է xmax պարամետրը: Ի՞նչ դեր է նա խաղում գործարքների կառավարումում: - Տողը եզակի նույնականացուցիչ ստեղծելու համար աղյուսակում - Տողը այլ գործարքների կողմից տեսանելիության ստուգելու համար - Տողը ջնջած կամ թարմացնող գործարքի համար նշելու համար - Տողը միաժամանակյա փոփոխություններից պաշտպանելու համար մի քանի գործարքների կողմից - Մաքսիմալ արժեքը ցույց տալու համար, որը կարող է գրանցվել թվային սյունակում
Ֆիթնես կլուբների այցելությունների վերլուծություն Դուք աշխատում եք ֆիթնես կլուբների ցանցում որպես վերլուծաբան: Ձեր ձեռքին կա օգտվողների այցելությունների և նրանց գնելած անդամակցությունների մասին տեղեկատվություն: Պետք է վերլուծել անդամակցությունների արդյունավետությունը: Հաշվեք յուրաքանչյուր անդամակցության տեսակի համար. • ընդհանուր օգտվողների թիվը, ովքեր օգտագործել են այդ տեսակի անդամակցությունը: Միայն հաշվի առեք յուրօրինակ user_id-երը; • այդ անդամակցությամբ կատարված ընդհանուր այցելությունների թիվը: Հաշվեք բոլոր այդ անդամակցությամբ օգտվողների այցելությունները; • այդ անդամակցության օգտվողների բաժինը ընդհանուր օգտվողների թվից տոկոսներով (մոտավորելով մեկ տասնորդական): Հաշվեք օգտվողների բաժինը՝ բաժանելով այդ անդամակցությամբ օգտվողների թվին ընդհանուր յուրօրինակ օգտվողների թվին: Յուրաքանչյուր օգտվող կարող է ունենալ միայն մեկ անդամակցություն: Արդյունքները դասավորեք անդամակցության տեսակի ըստ այբբենական կարգի: Մուտքային ձևաչափ Աղյուսակ memberships: • membership_id (int) — անդամակցության յուրօրինակ ID • user_id (int) — օգտվողի յուրօրինակ ID • membership_type (text) — անդամակցության տեսակը Աղյուսակ visits:
Որ հրամանը պետք է օգտագործել նախագծի հիմնական թղթապանակից՝ docs/ ենթամոդուլը թարմացնելու համար՝ հեռավոր պահոցից վերջին տարբերակին և այս փոփոխությունը պատրաստելու համար՝ կոմիտեի համար? 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 "Թարմացում" git submodule update --init docs/
Որոնք են Scala-ի վրա նախկինում աշխատած նախագծերը: Կիսվեք կոնկրետ առաջադրանքներով և ձեռքբերումներով այս տեխնոլոգիայում։
Ի՞նչ տեղի ունեցավ և ինչպես վերականգնել աշխատանքը։
Ինչ կարելի է ասել հետևյալ հարցման ճշգրտության մասին? select * from sessions where ended_at is null and status != 'pending';
Լոգիստիկ ընկերության համար զեկույց Դուք լոգիստիկ ընկերության վերլուծաբանի եք, որը վարում է պահեստների գործողությունների հաշվետվություն: Պատրաստեք յուրաքանչյուր պահեստի արդյունավետության մասին զեկույց: Հաշվեք յուրաքանչյուր պահեստի համար. • ընդհանուր գործողությունների քանակը (count_operations); • պահեստում մշակված ընդհանուր ապրանքների քանակը (sum_quantity); • գործողության միջին ժամանակը (avg_processing_time), հաշվի առնելով միայն նշված ժամանակով գործողությունները (ոչ NULL), կլորացրած ամբողջ թվով; • մեկ գործողության մեջ մշակված առավելագույն և նվազագույն ապրանքների քանակը (max_quantity, min_quantity); • յուրաքանչյուր տեսակի գործողությունների քանակը («մատակարարում», «ուղարկում», «փոխադրում») առանձին սյունակներում: supply_operations, shipment_operations, transfer_operations. Ֆիլտրեք պահեստները, որոնց ընդհանուր գործողությունների քանակը ավելի է, քան 2-ը և միջին ժամանակը չի գերազանցում 60 րոպեն: Արդյունքը դասավորեք պահեստի ID-ի աճման կարգով: Մուտքային ձևաչափ Գործողությունների աղյուսակ: • operation_id (int) — գործողության եզակի ID • warehouse_id (int) — պահեստի ID • operation_type (text) — գործողության տեսակ: «մատակարարում», «ուղարկում», «փոխադրում»
Դուք ունեք երկու կապված աղյուսակներ՝ first_table և second_table։ Դուք ցանկանում եք կատարել հրամանը TRUNCATE TABLE second_table CASCADE;, որպեսզի ջնջեք բոլոր տողերը second_table-ից և բոլոր կախված տվյալները։ Ինչ հետևանքներ կարող են լինել այս հրամանի կատարման դեպքում: create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - second_table_id_seq հաջորդականությունը վերականգնվում է սկզբնական արժեքին։ - Բոլոր գրառումները first_table-ից, որոնք կապված են second_table-ի հետ արտաքին բանալիով, ջնջվում են։ - Միջնորդական ցուցանիշները, որոնք առկա են second_table-ի համար, ջնջվում և ավտոմատ կերպով վերականգնվում են։ - Հաջորդ ներմուծումներում second_table-ում, id-ի նախնական արժեքը կարող է սկսվել սխալ արժեքից։ - Խնդիր առաջանում է, քանի որ CASCADE հրամանը արգելված է արտաքին բանալիներով աղյուսակների համար։
