Hur man övar SQL och Python tillsammans med realistiska problem

Hem » Python » Hur man övar SQL och Python tillsammans med realistiska problem

Om du försöker komma tillbaka till SQL och Python efter några år borta är det helt normalt att känna sig vilsen. – särskilt om din senaste roll använde proprietära verktyg och bekväma Databricks-anteckningsböcker som du inte längre har. Moderna jobbannonser som kräver Python, SQL och till och med PySpark kan se skrämmande ut när varje guide börjar med något i stil med "ladda in din datauppsättning för krav i ditt datalager" och du tänker: "Det är precis vad jag inte har."

Den goda nyheten är att du kan återskapa det mesta av den inlärningsupplevelsen på din egen bärbara dator. med hjälp av gratisverktyg, små exempeldataset och en strukturerad uppsättning övningsproblem. I den här guiden går vi igenom, på ett enkelt språk, hur man bygger en realistisk lokal miljö, hur SQL fungerar (från grundläggande frågor till JOIN och aggregering), och hur man paketerar dessa SQL-frågor i Python så att du kan öva exakt den typ av uppgifter du kommer att möta i moderna datajobb.

Bygga en enkel lokal övningsmiljö med SQLite och Python

Du behöver inte ett fullfjädrat datalager eller Spark-kluster för att öva på SQL plus PythonFör lärande och intervjuförberedelser är en lättviktig inbäddad databas som SQLite mer än tillräckligt. SQLite lagrar all sin data i en enda fil på disk, vilket gör den perfekt för leksaksprojekt, prototyper och utbildningsövningar.

Konceptuellt sett ser en SQLite-databas ut som ett kalkylblad med flera ark.varje ark är ett bord, varje rad är en post, och varje kolumn är en fältInom relationsdatabasjargong kallas tabeller ibland för "relationer", rader för "tupler" och kolumner för "attribut", men för praktiskt arbete kan du gärna hålla dig till de vardagliga termerna tabell, rad och kolumn.

Python levereras med en inbyggd SQLite-drivrutin som heter sqlite3., vilket innebär att du inte behöver installera en separat databasserver. Ditt Python-skript öppnar en anslutning till en .sqlite fil (skapa den om den inte finns), hämta en markören objekt (väldigt likt ett filreferens), och skicka sedan SQL-kommandon genom den markören med hjälp av execute(). Se vår SQLite SELECT och WHERE guide för praktiska exempel på läsning och filtrering av data.

Även om den här artikeln fokuserar på att driva SQLite från Python, finns det också ett praktiskt GUI-verktyg som heter "Database Browser for SQLite". (ibland distribuerad som DB Browser för SQLite). Med den kan du visuellt inspektera tabeller, infoga eller redigera några rader manuellt och köra enkla SQL-satser. Det är som en textredigerare för databasfiler: snabba manuella justeringar är enklare i det grafiska gränssnittet, men allt som är repetitivt eller komplext är bättre att skriva i Python.

Relationsdatabaser är mer rigida än Python-listor eller dikt: de insisterar på ett definierat schema.När du skapar en tabell måste du deklarera kolumnnamnen och de datatyper du förväntar dig (text, heltal, datum/tid, etc.). SQLite lagrar och indexerar sedan data på ett sätt som gör sökningarna effektiva, även när din datauppsättning växer bortom vad som bekvämt får plats i minnet. För praktiska inlärningsvägar och praktiska exempel, se [website address missing] SQL-dataanalys.

Skapa tabeller och infoga data med SQL och Python

För att börja öva behöver du först en tabell – tänk på det som att utforma formen på dina dataAnta att du vill ha en liten musikbibliotekstabell. Använd Pythons sqlite3 I modulen kan du ansluta till en databasfil, ta bort alla gamla versioner av tabellen om de finns, och sedan skapa en ny tabell med tydligt typade kolumner.

Så här ser flödet konceptuellt ut i Pythondu ringer sqlite3.connect('music.sqlite') för att öppna eller skapa databasfilen, anropa sedan conn.cursor() för att få en markör. Med hjälp av den markören kan du köra SQL-kommandon som DROP TABLE IF EXISTS Songs för att rensa eventuella tidigare scheman, följt av CREATE TABLE Songs (title TEXT, plays INTEGER) för att definiera en ny tabell med två kolumner.

När tabellen finns växlar du från DDL (Data Definition Language) till DML (Data Manipulation Language) med INSERT uttalandenI Python bör du alltid använda parametriserade frågor: write INSERT INTO Songs (title, plays) VALUES (?, ?) och skicka en tupel som ('Thunderstruck', 20) som det andra argumentet till execute()Frågetecknen är platsmarkörer som Python säkert kan ersätta, vilket hjälper dig att undvika problem med SQL-injektioner och citerande buggar.

Efter att du har utfört insättningar eller uppdateringar måste du ringa conn.commit() för att spola dina ändringar till diskenTills du genomför en commit finns operationerna endast i en transaktionsbuffert. Detta skiljer sig från enkla filskrivningar, och det är en av de viktigaste vanorna att bygga upp tidigt: fråga, ändra och sedan commit.

För att läsa tillbaka dina data använder du en SELECT satsen och iterera över markören. Till exempel, SELECT title, plays FROM Songs kommer att strömma varje rad som en Python-tupel, till exempel ('Thunderstruck', 20)Markören laddar inte alla resultat samtidigt; istället hämtar den rader långsamt, vilket är användbart när du så småningom hanterar större datamängder.

Kärnelement i SQL-frågesystem och filtrering med WHERE

Varje SQL-fråga bygger på en liten uppsättning klausuler som visas i en standardordning.: SELECT, FROM, WHERE, GROUP BY, HAVINGoch ORDER BYSom ett minimum anger du vilka kolumner du vill ha (SELECT) och från vilken tabell (FROMDe valfria klausulerna förfinar, aggregerar, filtrerar sedan aggregerade resultat och sorterar utdata.

Ocuco-landskapet WHERE klausulen filtrerar rader innan någon gruppering eller aggregering skerFör numeriska kolumner kan du använda jämförelseoperatorer som =, != (eller <>), >, <, >=, <=Textkolumner stöder dessa plus mönstermatchning via LIKE och medlemscheckar via INDatum-/tidsvärden stöder samma relationella jämförelser, och man ser ofta intervall uttryckta med BETWEEN.

Nullhantering i SQL är tillräckligt udda för att den förtjänar uttrycklig uppmärksamhet.Vanliga jämförelser som = och != inte uppföra sig som du kan förvänta dig med NULL, så SQL tillhandahåller IS NULL och IS NOT NULL för att kontrollera om det finns saknade värden. Booleska kolumner fungerar vanligtvis med = och !=, men du behöver fortfarande IS NULL när själva booleska värden kan saknas.

När du kombinerar flera villkor, kom ihåg att AND och OR följ prioriteringsreglerOm du skriver age < 5 OR age > 10 AND breed = 'Ragdoll', SQL kommer att utvärdera AND först. För att uttrycka "Ragdoll-katter yngre än 5 eller äldre än 10" ska du använda parenteser: (age < 5 OR age > 10) AND breed = 'Ragdoll'Att bli bekväm med dessa logiska kombinationer är avgörande för verkligt analysarbete.

Mönstermatchning med LIKE låter dig söka efter strängar som börjar, slutar eller innehåller vissa fragmentProcenttecknet % är ett jokertecken för valfri teckensekvens, så breed LIKE 'R%' hittar raser som börjar med "R", fav_toy LIKE 'ball%' hittar leksaker vars namn börjar på "boll", och coloration LIKE '%m' hittar färgmönster som slutar på "m". Parat med AND/OR, blir detta en kraftfull verktygslåda för textfiltrering.

Öva på frågor med en enda tabell med en leksaksdatauppsättning

Ett bra sätt att bygga muskelminne är att fixera ett litet schema i huvudet och lösa många frågor mot det.. Föreställ dig en cat tabell med kolumner som id, name, breed, coloration, age, sexoch fav_toyDetta ger dig tillräckligt med variation – text, siffror, enkla kategoriska termer – för att öva på de flesta grundläggande frågemönster.

För booleska kontroller filtrerar man ofta på en kolumn och lagerar sedan ytterligare villkorFör att lista "tråkiga" hankatter som inte har någon favoritleksak registrerad, skulle du välja name var sex = 'M' och fav_toy IS NULLDetta illustrerar hur nullkontroller paras ihop med enkla jämförelser för att isolera en specifik delmängd av rader.

För att rikta in sig på specifika raser eller exkludera dem kombinerar man jämlikhet med logisk negation.Att endast välja Ragdoll-katter med vissa åldrar använder breed = 'Ragdoll'; exklusive perser och siameser skulle kunna se ut så här breed NOT LIKE 'Persian' AND breed NOT LIKE 'Siamese'Medan vissa databaser stöder NOT IN ('Persian', 'Siamese'), att öva på det explicita mönstret hjälper till att befästa din förståelse av NOT och LIKE.

Övningar som "honkatter som älskar teaserleksaker och inte är perser- eller siameser" tvingar dig att blanda textfilter, likhet och logiska operatorer.Du skulle välja id, name, breed, coloration och begränsa raderna med hjälp av sex = 'F', fav_toy = 'teaser', och ett sammansatt villkor som exkluderar oönskade raser. Genom att vara uppmärksam på parenteser säkerställs att alla undervillkor tillämpas i den avsedda kombinationen.

När du är bekväm med dessa leksaksexempel i rå SQL, implementera dem igen via Python med hjälp av parametriserade frågor.Skriv korta manus som frågar efter ras, minimiålder eller leksakstyp från input(), anslut dem till WHERE klausuler och skriv ut resultaten. Detta är precis den brygga mellan frågeskrivning och verklig applikationskod som många junior dataroller förväntar sig.

Förstå och öva på SQL JOINs

Så fort du går förbi leksaksproblemen kommer du att sitta vid flera bord hela tiden.Med JOINs kopplar du samman relaterade datamängder: kunder till beställningar, konstnärer till konstverk, spel till företag och så vidare. I SQL beskriver du vilka kolumner som ska matcha mellan tabellerna, och databasmotorn sammanfogar raderna till en kombinerad resultatmängd.

Det finns fyra huvudsakliga typer av anslutningar som du kommer att stöta på i intervjuer och verkliga projekt: INNER JOIN (ofta skrivet bara JOIN), LEFT JOIN, RIGHT JOINoch FULL OUTER JOINEn inner join returnerar endast rader där båda tabellerna har matchande nycklar; en left join behåller alla rader från den vänstra tabellen och fyller i NULLs när den högra tabellen inte har någon matchning; en högerkoppling gör det symmetriska; och en fullständig yttre koppling returnerar varje rad från båda sidor, matchande där det är möjligt och med hjälp av NULL var inte.

Tänk på LEFT JOIN och RIGHT JOIN som operationer där man "litar mer på den här sidan"Med en vänsterkoppling är den vänstra tabellen den primära sanningskällan: varje rad från den förekommer minst en gång i utdata, även när den högra tabellen inte bidrar med något. Med en fullständig koppling har ingen sida privilegierad – du sammanfogar helt enkelt alla nycklar från båda tabellerna och justerar dem där de överlappar varandra.

För att hålla frågor med flera tabeller läsbara, aliasera alltid dina tabellerIstället för att skriva SELECT artist.name upprepade gånger, skriv FROM artist AS a och sedan referera till kolumner som a.name. Liknande, piece_of_art kan bli poaoch museum kan vara mNär din fråga växer till tre eller fler kopplingar är bra alias skillnaden mellan tydlighet och kaos.

En klassisk träningsuppsättning använder en trio av tabeller: artist, museumoch piece_of_art. De artist bordet kan hålla id, name, birth_year, death_year och ett primärt område som akvarell eller skulptur. museum bordsbutiker id, name och country. De piece_of_art bordhållare id, name, artist_id och museum_idDe två sista kolumnerna är främmande nycklar som länkar varje konstverk till dess skapare och plats.

Med det schemat kan du öva på inner joins, left joins och villkorliga filter.Om du till exempel vill lista konstnärer födda efter 1800 som levde mer än 50 år, tillsammans med namnen på deras verk, skulle du gå med i artist och piece_of_art on artist.id = piece_of_art.artist_id och filtrera sedan med death_year - birth_year > 50 och birth_year > 1800. Alias ​​de valda kolumnerna som artist_name och piece_name för tydlighets skull.

Att se alla konstverk tillsammans med museernas namn och länder – inklusive ”förlorade” verk utan museum – du skulle använda en LEFT JOIN från piece_of_art till museum on museum_idPå så sätt syns konstverk utan ett tillhörande museum fortfarande i resultatet, med NULL i museets kolumner. Filtrerar rader där artist_id IS NULL låter dig upptäcka verk av okända konstnärer samtidigt som du ansluter dig till museerna som innehar dem.

Mer avancerade övningar innebär att du går med i tre bord samtidigtFör att lista varje konstverk med både konstnären och museets namn, skulle du gå med i museum till piece_of_art on museum.id = piece_of_art.museum_id, gå sedan med artist on artist.id = piece_of_art.artist_idAnvända vanligt JOIN (inner join) tar avsiktligt bort konstverk som antingen saknar en konstnär eller ett museum, vilket ger dig en känsla för hur kopplingstypen påverkar radantalet.

Aggregering, GROUP BY och HAVING i praktiken

När du väl kan hämta och sammanfoga data är nästa stora färdighet att sammanfatta den.Aggregeringsfunktioner som SUM(), AVG(), COUNT(), MAX()och MIN() beräkna mätvärden över uppsättningar av rader. GROUP BY delar upp din datauppsättning i grupper och tillämpar dessa funktioner inom varje grupp – till exempel en grupp per år, per företag eller per konstnär. Om du föredrar strukturerade kurser för att öva på dessa koncept, se en omfattande SQL-kurs.

Tänk dig en enkel sales_table med kolumner year, monthoch salesEn slätt SELECT SUM(sales) AS total_sales FROM sales_table ger dig den totala summan över alla rader. Addera GROUP BY year ändrar frågan: nu frågar du efter total försäljning per år snarare än ett enda totalt antal.

Nyckelregeln är att varje icke-aggregerad kolumn i din SELECT måste förekomma i GROUP BY. Om du väljer year och SUM(sales), grupperar du efter year. Om du väljer year och month tillsammans med aggregat, grupperar du sedan efter båda year och monthKonceptuellt definierar distinkta kombinationer av de grupperade kolumnerna grupperna.

WHERE och HAVING är båda filter, men de verkar i olika steg. WHERE filtrerar råa rader innan någon gruppering eller aggregering sker. HAVING filtrerar de grupperade resultaten med hjälp av aggregerade uttryck. Du kan till exempel WHERE production_year BETWEEN 2000 AND 2009 och då HAVING SUM(revenue) > 4000000 att endast behålla företag vars ”bra spel” genererade mer än fyra miljoner i intäkter.

Ett mer realistiskt övningsschema är ett games bord med kolumner som id, title, company, type, production_year, system, production_cost, revenueoch ratingMed den här enda tabellen kan du använda medelvärden, antal, summeringar, gruppering och rangordning – själva grunden för analys-SQL.

Till exempel, för att beräkna den genomsnittliga produktionskostnaden för spel som släpptes från 2010 till 2015 med ett betyg högre än 7, skulle du välja AVG(production_cost) och begränsa rader med WHERE production_year BETWEEN 2010 AND 2015 AND rating > 7Det är en klassisk intervjufråga, och du kan enkelt bädda in den i Python och skriva ut det resulterande enskilda numret.

Du kan också skapa statistik på årsnivå direkt från samma games bordGruppera efter production_year, beräkna sedan COUNT(*) AS count, AVG(production_cost) AS avg_costoch AVG(revenue) AS avg_revenueDen här typen av fråga ger dig en kompakt tidsserievy som är extremt vanlig i BI-instrumentpaneler och rapporteringsverktyg.

För att rangordna företag efter bruttovinst över alla år kan du aggregera på companyEtt praktiskt mönster är SELECT company, SUM(revenue - production_cost) AS gross_profit_sum FROM games GROUP BY 1 ORDER BY 2 DESC. Här GROUP BY 1 och ORDER BY 2 använd kolumnpositioner i SELECT lista, vilket kan hålla saker koncisa men måste användas försiktigt så att du inte förstör frågor genom att ändra ordning på kolumner senare.

Mer komplexa uppmaningar knyter ihop filter, grupperings- och efteraggregeringsfilterAnta att du definierar "bra spel" som de som producerades mellan 2000 och 2009, med ett betyg över 6 och en intäkt större än produktionskostnaden. För varje företag vill du ha antalet sådana spel plus deras totala intäkter, men bara för företag vars intäkter från bra spel överstiger 4 000 000. Du skulle filtrera rader med WHERE on production_year, ratingoch lönsamhet, gruppera efter company, beräkna COUNT(company) och SUM(revenue), applicera sedan HAVING SUM(revenue) > 4000000Den här frågan fångar upp de flesta av de verkliga mentala stegen du kommer att stöta på i analysuppgifter.

Modellera data med flera tabeller och nycklar

Med en enda tabell kommer man ganska långt, men relationsdatabaser blir bättre när man normaliserar data över flera tabellerNormalisering är processen att eliminera redundant lagring och representera relationer via nycklar. Det gör att din databas blir mindre, snabbare och mindre felbenägen.

Ett enkelt men lärorikt exempel kommer från att genomsöka Twitter-liknande sociala graferSäg att du vill spåra användarkonton och "följar"-relationerna mellan dem. En naiv metod skulle vara en enda tabell där varje rad duplicerar både följar- och följarnamn som text. Det leder snabbt till många upprepningar och inkonsekvent stavning.

Istället delar du upp saker i en People bord och ett Follows bord. People kan ha ett heltal id som primärnyckel, en unik name (skärmnamnet eller användarnamnet) och en retrieved flagga som signalerar om du redan har genomsökt det kontots vänlista. Follows innehåller par av heltal from_id och to_id, som representerar riktade anslutningar från en användare till en annan.

Tre nyckelbegrepp strukturerar denna modell: logiska nycklar, primärnycklar och främmande nycklarEn logisk nyckel är vad omvärlden använder för att referera till en post – här Twitter-användaren i nameEn primärnyckel är vanligtvis ett databasgenererat heltal (id) som unikt identifierar varje rad och är billig att indexera och jämföra. En främmande nyckel är ett heltal som pekar på en primärnyckel i en annan tabell – from_id och to_id i Follows tabellen refererar till främmande nycklar People.id.

För att säkerställa datakvaliteten deklarerar du begränsningar i dina tabelldefinitioner. Till exempel, name TEXT UNIQUE in People säkerställer att du inte av misstag kan infoga två rader med samma handtag. UNIQUE(from_id, to_id) begränsning i Follows hindrar dig från att lagra samma följekant mer än en gång. Dessa begränsningar fungerar även som skyddsnät när du börjar skriva upsert-logik i Python.

I Pythons sqlite3 modul, ett vanligt mönster är att använda INSERT OR IGNORE att respektera dessa begränsningar på ett värdigt sättOm du försöker infoga en name som redan finns, kommer SQLite tyst att hoppa över operationen istället för att ge ett felmeddelande. Du kan sedan kontrollera cursor.rowcount för att se om en rad verkligen lades till, och förlita sig på cursor.lastrowid att upptäcka det tilldelade id för nyligen inlagda användare.

När din kod får ett nytt skärmnamn bör den först försöka slå upp motsvarande id. Om en SELECT id FROM People WHERE name = ? returnerar en rad, du återanvänder det heltalet. Om inte, infogar du namnet med retrieved = 0, commit och läs sedan lastrowidDet där "sök eller infoga"-mönstret är kärnan i många datainmatningsskript.

När både följar- och följar-ID är kända, registreras relationen i Follows är bara en annan INSERT OR IGNORE. Din UNIQUE(from_id, to_id) begränsningen åtgärdar dubbletter, och du kan koncentrera dig på den överordnade logiken för vilka profiler som ska crawlas härnäst, snarare än att mikrohantera raddeduplicering.

Använda JOIN för att rekonstruera relationer från normaliserade tabeller

Normaliserade scheman byter redundans mot indirektion: du lagrar heltal istället för upprepade strängar, men nu måste du koppla ihop tabeller för att rekonstruera hela bilden. Det här är precis vad SQL JOIN var designad för, och när du väl vant dig vid det, känns JOIN-tunga frågor helt naturliga.

I exemplet med social graf, om du vill se vilka användare med id = 2 följer, skulle du gå med Follows till People på målsidan. Konceptuellt sett springer du SELECT * FROM Follows JOIN People ON Follows.to_id = People.id WHERE Follows.from_id = 2Detta producerar kombinerade rader som innehåller både den numeriska kanten och det mänskligt läsbara namnet för varje följare.

Varje rad i det resultatet är en "metarad" som sammanfogar kolumner från båda tabellerna.De två första kolumnerna kan vara (from_id, to_id) från Follows, medan de efterföljande kolumnerna tillhör People - tycka om (id, name, retrieved). Eftersom JOIN villkor upprätthåller Follows.to_id = People.id, kan du se det sambandet explicit: den andra kolumnen och den tredje kolumnen på varje rad matchar.

Samma mönster sträcker sig naturligt till fler tabellerDu har redan sett det med artist, piece_of_artoch museum, och Twitter-crawlern illustrerar det med People och FollowsI mer komplexa analyspipelines kan du koppla samman faktatabeller (händelser, ordrar) med tabeller med flera dimensioner (användare, produkter, kampanjer) för att besvara mångfacetterade frågor.

När du felsöker din kod eller lär dig hur schemat passar ihop är ett arbetsflöde som "kör Python och inspektera sedan med DB Browser för SQLite" extremt effektivt.Kör ditt skript för att fylla databasen, stäng alla GUI-instanser som håller filen låst och öppna sedan .sqlite filen i webbläsaren. Därifrån kan du granska innehållet i varje tabell och köra ad hoc-filer. SELECT frågor för att verifiera dina antaganden.

En varning: SQLite tillämpar fillås, så om DB-läsaren har databasen öppen i redigeringsläge kan det hända att ditt Python-skript misslyckas med att ansluta eller genomföra.Lösningen är att stänga databasen i det grafiska gränssnittet (eller avsluta webbläsaren helt) innan du kör din Python-kod igen. Att vänja sig vid att stänga verktyg som låser din databasfil kommer att rädda dig från mystiska felmeddelanden som säger att "databasen är låst".

Genom att sammanföra dessa tekniker – schemadesign, begränsningar, parametriserade frågor i Python, JOINs, GROUP BY och HAVING – får du ett kraftfullt lokalt labb. för att öva exakt den typ av SQL- och Python-arbete som du kommer att göra på jobbet. Med inget mer än SQLite och några välstrukturerade exempeltabeller kan du repetera intervjuliknande frågor, prototypa analytisk logik och återfå ditt självförtroende med moderna dataverktyg.

Där plattformar som DataLemur och interaktiva kurser passar in

Utöver din lokala praxis kan interaktiva plattformar ge dig en mer guidad upplevelse med omedelbar feedbackVerktyg som är sprungna ur verklig branscherfarenhet – till exempel plattformar skapade av tidigare dataingenjörer från Facebook och Google som tillbringade sina dagar med att skriva SQL och Python och köra A/B-tester – centrerar ofta sitt innehåll kring genuina intervjufrågor och analysscenarier.

Böcker som täcker statistik, maskininlärning och affärsintuition för dataintervjuer är utmärkta för teori, men de erbjuder inte alltid den praktiska SQL-lekplats som många elever längtar efter. Det gapet är precis vad vissa moderna verktyg syftar till att fylla: de paketerar om hundratals intervjuliknande frågor till en SQL- och analysmiljö i webbläsaren så att du kan köra, justera och köra om dina frågor utan att behöva oroa dig för den lokala konfigurationen. Du kan också prova tillämpade exempel som utvärdering av risken för kundbortfall att kombinera SQL med grundläggande maskininlärningsarbetsflöden.

Du hittar också interaktiva SQL-kurser som speglar de ämnen vi har gått igenom här.: frågor med en enda tabell med SELECT och WHERE, kopplingar mellan två eller tre tabeller, aggregering och gruppering, delfrågor och mer. Många av dessa kurser förlitar sig på realistiska datamängder – tänk spel, museer eller transaktionell försäljning – så att frågorna känns som genuina affärsproblem snarare än påhittade pussel.

Om du känner dig överväldigad av dokumentation för verktyg som PySpark, DuckDB eller dbt, är det helt rimligt att skjuta upp dem tills dina SQL-grunder känns solida.Genom att först fokusera på SQLite plus Python kan du internalisera de centrala frågemönstren utan att behöva kämpa med klusterkonfiguration eller molnbehörigheter. När grunderna väl är en självklarhet handlar det mer om distribuerad exekvering än om nya frågekoncept att lära sig PySpark.

I slutändan kombinationen av en enkel lokal uppställning, strukturerade övningsproblem och tillfällig användning av interaktiva plattformar ger dig det bästa av alla världar: full kontroll över din miljö, stark konceptuell grund och exponering för den typ av frågor som topparbetsgivare älskar. Med stadig övning blir den en gång så skrämmande blandningen av SQL, Python och datatekniska verktyg en välbekant, till och med trevlig, verktygslåda som du tryggt kan använda i nya roller.

Sammantaget är din väg framåt tydlig: skapa en SQLite-databas med Python, designa några realistiska tabeller, drilla grundläggande och mellanliggande SQL-mönster (filter, joins, aggregering, gruppering, HAVING), linda in dessa frågor i Python-skript och komplettera eventuellt ditt lärande med interaktiva SQL-plattformar byggda av utövare som har varit precis där du är nu.Genom att göra det kommer du att återuppbygga dina tekniska instinkter, minska oron kring moderna datastackar och vara redo att hantera SQL- och Python-kraven i dagens dataroller.