Fitness klubok látogatottsági elemzése Ön egy fitness klubokat hálózatban dolgozó elemzőként. Információkkal rendelkezik a felhasználók látogatásairól és az általuk vásárolt tagságokról. Elemzéseket kell végeznie a tagságok hatékonyságáról. Számolja ki minden tagságtípus esetén: • az ezen típusú tagságot használó felhasználók összes számát. Csak az egyedi user_id-ket vegye figyelembe; • az ezen tagsággal kapcsolatos összes látogatást. Vegye figyelembe az összes ilyen tagsággal rendelkező felhasználó látogatását; • az adott tagságtípusú felhasználók arányát százalékban az összes felhasználóhoz képest (kerekítve egy tizedesre). A számításhoz használja az adott tagságtípussal rendelkező felhasználók számának és az összes egyedi felhasználó számának arányát. Minden felhasználónak csak egy tagsága lehet. Rendezze az eredményt tagságtípus szerint alfabetikus sorrendbe. Bemeneti formátum Memberships táblázat: • membership_id (int) — egyedi tagságazonosító • user_id (int) — felhasználó azonosító • membership_type (text) — tagságtípus Visits táblázat: • visit_id (int) — egyedi látogatásazonosító • user_id (int) — felhasználó azonosító • visit_date (timestamp) — látogatás dátuma és időpontja Az adatok nem tartalmaznak hiányzó vagy hibás értékeket. Kimeneti formátum A lekérdezésnek olyan táblát kell visszaadnia, amely a következő mezőket tartalmazza ebben a sorrendben: • membership_type (text) — tagságtípus • users_count (int) — ezen típusú felhasználók száma • total_visits (int) — ezen felhasználók összes látogatásának száma • user_share (numeric) — ezen típusú felhasználók aránya százalékban az összes felhasználóhoz képest, egy tizedesre kerekítve Az eredményt tagságtípus szerint alfabetikus sorrendbe rendezze.
Data Engineer
Ismeri a Domain Driven Design (DDD) módszertant? Ha igen, ossza meg példáit annak alkalmazásáról projektjeiben.
Hogyan távolítható el egy almappa és a vele kapcsolatos fájlok a projektből? git submodule remove <almodul-útvonal> git rm --cached <almodul-útvonal>; törölje a szakaszt a .gitmodules fájlból; git commit git clean --submodules <útvonal> git submodule delete <útvonal> git remove submodule <útvonal>
Melyik kifejezés a [...] helyén automatikusan indexet hoz létre? Mobil platformon vízszintes görgetés van a kódban create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Logisztikai vállalat jelentése Ön egy logisztikai vállalat elemzője, aki a raktárak műveleteit nyilvántartja. Jelentést kell készítenie minden raktár hatékonyságáról. Minden raktár esetében számolja ki: • a műveletek összes száma (count_operations); • a raktárban feldolgozott termékek összes száma (sum_quantity); • az átlagos feldolgozási idő (avg_processing_time), csak a megadott idővel (nem NULL) rendelkező műveleteket figyelembe véve, a legközelebbi egész számra kerekítve; • a maximális és minimális termékszám, amit egy műveletben feldolgoztak (max_quantity, min_quantity); • az egyes típusú műveletek száma («beszállítás», «kiszállítás», «átvitel») külön oszlopokban: supply_operations, shipment_operations, transfer_operations. Szűrje ki azokat a raktárakat, ahol az összes művelet száma több mint 2, és az átlagos feldolgozási idő nem haladja meg a 60 percet. Rendezze az eredményt a raktár azonosítója szerint növekvő sorrendben. Bemeneti formátum operations tábla: • operation_id (int) — művelet azonosítója • warehouse_id (int) — raktár azonosítója • operation_type (text) — művelet típusa: «beszállítás», «kiszállítás», «átvitel» • quantity (int) — a műveletben lévő termékek száma • operation_date (timestamp) — a művelet dátuma és időpontja • processing_time (int) — a művelet feldolgozási ideje A processing_time oszlop NULL értékeket tartalmazhat. Kimeneti formátum A lekérdezésnek egy olyan táblát kell visszaadnia, amely a következő mezőket tartalmazza a megadott sorrendben: • warehouse_id (int) — raktár egyedi azonosítója • count_operations (int) — a raktárban végrehajtott összes művelet száma • sum_quantity (int) — a raktárban feldolgozott összes termék száma • avg_processing_time (numeric) — a művelet átlagos feldolgozási ideje (percben), csak a nem NULL idővel rendelkező műveleteket figyelembe véve, a legközelebbi egészre kerekítve • max_quantity (int) — egy műveletben feldolgozott maximális termékszám • min_quantity (int) — egy műveletben feldolgozott minimális termékszám • supply_operations (int) — «beszállítás» típusú műveletek száma • shipment_operations (int) — «kiszállítás» típusú műveletek száma • transfer_operations (int) — «átvitel» típusú műveletek száma
A git bisect használata közben olyan commit-tal találkoztál, amit nem lehet ellenőrizni a szükséges környezet hiánya miatt. Mit kell ilyenkor tenni? - Ismételd meg a git bisect start parancsot más hash-ekkel - Hagyd ki ezt a commit-ot a git bisect skip parancs segítségével - Állítsd vissza a bisect-et a git bisect reset parancs segítségével - Jelöld meg a commit-ot jóként a git bisect good parancs segítségével - Jelöld meg a commit-ot rosszként a git bisect bad parancs segítségével
Miért nem fogja a következő lekérdezés használni a indexet, ha a records (id) táblában egy normál B-tree index van az id-n? select * from records where id % 2 = 0 - GIN típusú index szükséges az id-hez - Az indexek nem működnek a WHERE kifejezésekkel - % összehasonlítási művelet, nem szűrés - limit és offset kötelező az indexes optimalizáláshoz - A lekérdezés egy numerikus mezőre hivatkozik, nem szövegesre
Magyarázza el, hogyan működik technikailag a Git LFS, és milyen előnyöket nyújt a standard Githez képest nagy fájlok esetén.
Egy speciális szekvencia lett létrehozva, mely neve even_sequence, és csak páros számokat generál. Mit kell beírni [...]-be, hogy ha az even_column értékét nem adták meg beszúráskor, akkor az érték az even_sequence-ből származzon? create table some_table( even_column [...] ); integer computed as nextval('even_sequence') integer generated always as identity (start with 2 increment by 2) integer default nextval('even_sequence') integer unique default nextval('even_sequence') integer generated by even_sequence’
Van tapasztalata a Langchain könyvtárral kapcsolatban? Milyen feladatokat oldott meg vele?
Mit szeretnél csinálni a csapatunkban?
Olyan összekapcsolási típust kell használni, amelyben a lekérdezésben szerepelnek mind a felhasználók, mind a legutóbbi rendeléseik, még akkor is, ha nincsenek rendeléseik. Táblák: users(id, name) és orders(id, user_id, created_at). CROSS JOIN RIGHT JOIN INNER JOIN FULL JOIN LEFT JOIN
Melyik az alábbi állítás tükrözi az ilyen műveletek következményeit a kibővített Git Flow és a változások történetének kezelésének szempontjából?
Hogyan javasolja a Git Flow az alkalmazás új kiadásának formalizálását? - Új issue-ág létrehozásával - Hotfix-ág létrehozásával a masterből - Egy külön release-ág létrehozásával a developből - Közvetlen commitálással a master ágba - A master ág közvetlen összevonásával a developdel
Felfedezted, hogy a Git fő tárhelyének történetében olyan commitok vannak, amelyek kritikus bizalmas adatokat tartalmaznak. Ezeket az adatokat teljesen el kell távolítani az egész tárhely történetéből. Értékeld, mennyire helyes és biztonságos a következő stratégia alkalmazása: hozz létre egy új commitot, amely eltávolítja a bizalmas adatokat a fájlok aktuális verziójából, és küldd el a main-be. - Helyes, de nem optimális. Jobb a git revert használata a commitok visszavonására - Feltételesen helyes. Ez ideiglenes megoldás, amíg nem találunk radikálisabb módszert az adatok eltávolítására - Helytelen és nem biztonságos. Az adatok eltávolításra kerülnek az aktuális verzióból, de hozzáférhetőek maradnak a tárhely történetében - Helytelen. Ez a commit konfliktusokat okozhat más ágak összeolvasztásakor - Helyes és biztonságos. Ez a módszer garantálja, hogy az adatok eltávolításra kerülnek, és többé nem jelennek meg a tárhelyen
A dev ágban dolgozik egy új funkción. Hirtelen szükségessé válik, hogy gyorsan átváltson a main ágra, hogy gyorsan javítson egy helyesírási hibát a README.md fájlban. Néhány nem commitolt változtatása van: src/feature.js (nem staged) és styles/main.css (staged). Ideiglenesen el szeretné menteni ezeket a változtatásokat, hogy később visszatérhessen rájuk a dev ágon. Milyen parancssorozatot kellene használnia ehhez? git stash save "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash push -m "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash && git checkout main && [fix] && git checkout dev && git stash apply git add . && git stash && git checkout main && [fix] && git checkout dev && git stash drop git commit -m "Temp commit" && git checkout main && [fix] && git checkout dev && git reset HEAD^
Eladási elemzés termékkategóriánként egy kiskereskedelmi üzletben Ön egy kiskereskedelmi üzlet elemzője. Feladata, hogy kategóriánkénti értékesítési jelentést készítsen a következő számításokkal: • az adott kategóriában eladott összes egység száma (total_units_sold); • az adott kategória összbevételét figyelembe véve, kedvezményekkel, ahol a kedvezmény a következőképpen számítódik: unit_price × units_sold × (1 − discount/100). Ha a kedvezmény NULL, akkor 0%-nak tekintjük. Kerekítse két tizedesjegyre; • az egy eladásra jutó átlagos eladott egységek száma (avg_units_per_sale), két tizedesjegyre kerekítve; • a kedvezmény nélküli eladások aránya (no_discount_share) — a NULL vagy 0% kedvezménnyel történt eladások száma, osztva az összes eladással az adott kategóriában, három tizedesjegyre kerekítve. Először rendezze az eredményeket összbevétel szerint csökkenő sorrendben, majd az eladásonkénti átlagos egységszám szerint növekvő sorrendben, végül a kategória nevének ábécé sorrendjében. Bemeneti formátum Eladási tábla: • sale_id (int) — egyedi eladási azonosító • product_id (int) — termék azonosító • category (text) — termékkategória • sale_date (timestamp) — eladási dátum és idő • units_sold (int) — eladott egységek száma • unit_price (numeric) — egységár • discount (numeric) — kedvezmény százalékban, NULL lehet A discount oszlop tartalmazhat hiányzó értékeket. Kimeneti formátum A lekérdezésnek olyan táblát kell visszaadnia, amely a következő mezőket tartalmazza ebben a sorrendben: • category (text) — termékkategória • total_units_sold (int) — az adott kategóriában eladott összes egység száma • total_revenue (numeric) — összbevétel kategóriánként, két tizedesjegyre kerekítve • avg_units_per_sale (numeric) — eladásonkénti átlagos egységszám, két tizedesjegyre kerekítve • no_discount_share (numeric) — a kedvezmény nélküli eladások aránya (érték 0 és 1 között), három tizedesjegyre kerekítve Az eredményt először összbevétel szerint csökkenő sorrendben, majd az eladásonkénti átlagos egységszám szerint növekvő sorrendben, végül a kategória nevének ábécé sorrendjében kell rendezni.
Van tapasztalata a Gin web-keretrendszerrel? Részletesebben meséljen arról, milyen feladatokat oldott meg vele.
[név] kijavította a hibákat és a stílust a szövegben: «Szia! Én vagyok [név], korábban kérted, hogy váltson át Telegramra» — tisztelettel, de barátságosan
A PostgreSQL-ben tranzakciók teljesítményének optimalizálásához minimális izolációs szintet kell alkalmazni, amelynél: • párhuzamos tranzakciók láthatják egymás befejezetlen változásait; • lehetőség van "szennyezett olvasásokra" (dirty read). Milyen izolációs szintet kell megadni a tranzakcióhoz, hogy elérjük ezt a célt? A dirty read nem lehetséges PostgreSQL-ben repeatable read read uncommitted read committed serializable