Vanlige SQL- og Python-problemer og hvordan håndtere dem

Home » Python » Vanlige SQL- og Python-problemer og hvordan håndtere dem

Å jobbe med SQL og Python sammen er en av de kraftigste kombinasjonene innen data- og backend-utvikling, men det åpner også døren for en lang liste med subtile feil, konfigurasjonsfeller og ytelsesoverraskelser. Hvis du noen gang har stirret på en kryptisk sporing mens databasetilkoblingen din «bare burde fungere», eller lurt på hvorfor det samme analytiske skriptet kjører lynraskt på den bærbare datamaskinen din, men kryper inn i SQL Server, er du ikke alene.

Denne veiledningen samler SQL-Python-problemer fra den virkelige verden, lavnivåproblemer med SQL Server Machine Learning Services og praktiske mønstre for bruk av begge språkene i analyser.I stedet for vage råd finner du konkrete eksempler, typiske feilmeldinger og trinnvise ideer for å diagnostisere og fikse problemer, pluss en fullstendig gjennomgang av hvordan du designer, spør og manipulerer databaser i Python ved hjelp av SQLite og andre motorer.

Vanlige tilkoblingsproblemer mellom SQL og Python

Et av de første smertepunktene når man blander SQL og Python er rett og slett å få en stabil forbindelse.Selv når legitimasjonsinformasjon og DSN-er ser riktige ut, kan små avvik i drivere, stier eller miljøer utløse forvirrende kjøretidsfeil i det øyeblikket du starter app.py eller kjører et skript fra kommandolinjen.

I virtualiserte miljøer blir dette mer sårbartFor eksempel kan du kjøre SQLite eller SQL Server i en virtuell maskin mens du utvikler på verts-OS-et og tester tilkoblingen med et grafisk verktøy som SQL Developer eller SQL Server Management Studio. Det grafiske grensesnittet kobler seg til uten problemer, men Python-skriptet mislykkes fordi det bruker en annen driver, et manglende bibliotek eller en helt annen nettverksbane.

Typiske tilkoblingsproblemer inkluderer manglende ODBC/DB API-drivere, feil DSN-konfigurasjon, blokkerte porter og uoverensstemmelser i autentiseringsmoduser.Det er veldig vanlig å se Python generere generiske unntak som «kunne ikke koble til», mens det underliggende problemet er at systemet ikke kan laste inn et delt bibliotek (for eksempel libc++ eller libc++abi på Linux) eller ikke finner den forventede ODBC-driveren for SQLite, PostgreSQL, MySQL eller SQL Server.

Når du kobler til fra Python, bruker du vanligvis biblioteker som sqlite3, psycopg2, pyodbc, mysql-connector-python, PyMySQL eller et ORM-lag som SQLAlchemy.Hver av dem har sitt eget format for tilkoblingsstrenger, feiltyper og avhengigheter. En GUI-klient kan bruke en annen driverstabel som skjuler disse problemene, så bekreft alltid nøyaktig hvilke driver- og tilkoblingsparametere Python-koden din bruker.

Hvorfor det er strategisk effektivt å kombinere SQL og Python

Utover de tekniske hodepinene, er det en strategisk grunn til at utviklere og analytikere stadig insisterer på å kombinere Python med SQL.Hvert språk dekker en annen del av datalivssyklusen, og sammen gir de deg en ende-til-ende-arbeidsflyt som er vanskelig å matche med et enkelt verktøy.

SQL er fortsatt standarden for relasjonsdatahåndteringDen utmerker seg på godt strukturerte data, relasjonell integritet, indeksering og transaksjonelle arbeidsbelastninger. Med SQL får du rask filtrering, sammenføyning og aggregering over store datasett, enhetlig tilgang for mange verktøy og forutsigbar ytelse støttet av flere tiår med databaseforskning.

Python skinner når dataene forlater databasekontekstenMed biblioteker som pandas, NumPy, matplotlib og seaborn kan du rense, omforme og analysere data på vilkårlig komplekse måter, kjøre statistikk eller maskinlæring, og bygge visualiseringer eller rapporter programmatisk, inkludert sanntids dataanalyseMange transformasjoner som er vanskelige eller ordrike i SQL blir enkle Python-uttrykk.

I praksis betyr dette en klar arbeidsfordeling: skyv så mye filtrering, aggregering og grunnleggende transformasjon som mulig ned i SQL, og bring deretter et ryddig datasett tilbake i Python for omfattende analyser, modellering eller visualisering. Analytikere og ingeniører som behersker begge språkene flytende, kan raskt gå fra et forretningsspørsmål til en reproduserbar dataportefølje.

Koble Python til SQL-databaser: biblioteker og mønstre

For at SQL og Python skal fungere pålitelig sammen, trenger du de riktige koblingene og litt disiplin rundt hvordan du åpner, bruker og lukker databaseøkterDen nøyaktige stakken avhenger av databasemotoren, men konseptene er like.

For lette, innebygde arbeidsflyter er SQLite ofte det enkleste valgetPython leveres med sqlite3-modulen i standardbiblioteket, slik at du kan opprette en databasefil, definere tabeller og kjøre spørringer uten å installere ekstra programvare. Dette er perfekt for prototyper, små analyseprosjekter eller undervisning i relasjonelle konsepter.

For serverbaserte databaser bruker du vanligvis motorspesifikke drivere eller en ORM.PostgreSQL brukes mye med psycopg2, SQL Server bruker ofte pyodbc eller Microsofts ODBC-driver, og MySQL/MariaDB bruker mysql-connector-python eller PyMySQL. I tillegg til dette tilbyr SQLAlchemy et abstraksjonslag på høyt nivå som lar deg skrive portable SQL-uttrykk og administrere tilkoblingspooler.

Et robust tilkoblingsmønster innebærer å lese legitimasjonsinformasjon fra miljøvariabler eller en hemmelighetsbehandling, bruke parameteriserte spørringer for å unngå injeksjon og bruke riktig feilhåndteringEtter hver arbeidsenhet bør du eksplisitt sende eller rulle tilbake transaksjoner og frigjøre tilkoblingen tilbake til poolen eller lukke den, i stedet for å holde mange inaktive økter åpne.

Med SQLAlchemy og pandas blir arbeidsflyten spesielt smidigDu konstruerer en tilkoblings-URL, oppretter en motor, og bruker deretter pandas.read_sql_query til å hente spørreresultater direkte inn i en DataFrame. Derfra har du full kraft i Python-økosystemet for å rense, analysere og eksportere data.

Maskinlæringstjenester i SQL Server: Problemer med integrering av R og Python

Microsoft SQL Server inkluderer en funksjon kalt Machine Learning Services som bygger inn R- og Python-kjøretider i databasemotoren., slik at du kan kalle eksterne skript via sp_execute_external_script. Dette er kraftig for analyse i databasen, men det kommer med en lang liste med versjonsspesifikke feil og begrensninger du må forstå.

Installasjons- og oppgraderingsproblemer er spesielt vanlige i SQL Server 2016, 2017, 2019 og 2022.Problemene spenner fra manglende R-komponenter på spesifikke Azure VM-bilder, til ufullstendige Python-installasjonsprogrammer på tidlige SQL Server 2017-bygg, til CU-pakker (kumulative oppdateringer) som ikke ber om frakoblede R-oppdateringer. I noen tilfeller må du sende tilleggsparametere, for eksempel MRCACHEDIRECTORY, på kommandolinjen for å peke oppsettet til hurtigbufrede CAB-filer.

Det finnes også plattformspesifikke avhengighetsproblemerPå Linux-bygg av SQL Server 2019 og senere kan det hende at R- og Python-kjøretider ikke starter fordi delte biblioteker som libc++.so.1 eller libc++abi.so.1 ikke er tilgjengelige i banen til utvidbarhetsbiblioteket. De resulterende feilene vises ofte som generiske meldinger om at «Kan ikke kommunisere med kjøretiden» i SQL Server, mens startpanelloggene avslører den manglende .so-filen. Rettelser innebærer vanligvis å kopiere de nødvendige delte bibliotekene til /opt/mssql-extensibility/lib eller eksponere mapper via mssql.conf.

På Windows-servere konfigurert med FIPS-kryptografiinnstillinger finnes det en annen type installasjonsfeilForsøk på å aktivere maskinlæringstjenester eller språkutvidelser kan føre til feil om at AppContainer-oppretting ikke er kompatibel med Windows Platform FIPS-validerte algoritmer. Løsningen er å midlertidig deaktivere FIPS, fullføre installasjonen eller oppgraderingen, og deretter aktivere FIPS på nytt etter at SQL Server er fullstendig konfigurert.

Noen kumulative oppdateringer introduserer forbigående regresjoner som påvirker skriptkjøringen.For eksempel inkluderte SQL Server 2017 CU-er 5–7 en feil i rlauncher.config der den midlertidige katalogbanen inneholdt mellomrom, noe som førte til at R-skript feilet med meldingen «kan ikke opprette R_TempDir». Senere CU-er fikset dette, men frem til da måtte administratorer registrere det eksterne skriptmiljøet på nytt ved hjelp av RegisterRExt.exe med flagg for avinstallering og installasjon.

Versjonsavvik mellom klient- og serverkjøretider

En annen tilbakevendende kilde til forvirring er versjonskompatibilitet mellom klientverktøy (Microsoft R Client eller Python-pakker) og serversidekjøretider (R Server eller SQL Server Machine Learning Services).Når du kjører eksterne skript fra en klient mot en eldre SQL Server-forekomst, kan et avvik utløse eksplisitte feil eller subtile serialiseringsproblemer.

I SQL Server 2016 R Services må klient- og server-R-bibliotekversjoner samsvare nøyaktigHvis du kjører Microsoft R Client 9.x mot en server med R Server 8.0.3, får du meldinger som sier at klienten din er inkompatibel og foreslår at du installerer en samsvarende versjon. Senere versjoner har lempet på dette kravet, men hvis du ser disse feilene, må du bekrefte begge sider og enten oppgradere serveren eller installere en kompatibel klient.

Serialisering og deserialisering av trente modeller er spesielt følsomme for versjonsforskjeller.Med RevoScaleR i R og revoscalepy i Python kan det hende at en modell som er serialisert med et nyere API, ikke klarer å deserialisere på en server som bruker en eldre serialiseringsinfrastruktur. Dette kan føre til interne feil som memDecompress-feil i R eller NameError i Python når rx_unserialize_model ikke er definert. Oppgradering av SQL Server-forekomsten til minst CU3 for SQL Server 2017 løser vanligvis disse avvikene.

Forhåndstrente modeller installert på SQL Server 2017 kan også treffe begrensninger i banelengdeTidlige versjoner lagret modellbinærfiler i dype katalogstrukturer under standard forekomststi, og Python kunne ikke åpne filene fordi hele stien overskred OS-grensene. Foreslåtte rettelser inkluderte å installere modeller til en tilpasset kortere sti, installere SQL Server i en kortere rotkatalog, eller til og med opprette NTFS-hardlinker med fsutil for å eksponere et kortere alias til den samme filen.

Når du designer en løsning ved hjelp av SQL Server Machine Learning Services, må du alltid låse versjonene og CU-nivåene dine som en del av distribusjonsplanen.Å spre skript på tvers av flere servere med forskjellige CU-nivåer uten å spore disse detaljene er en oppskrift på vanskelige feilsøkingsproblemer med serialisering og kjøretid senere.

Ressursstyring, ytelse og kaldstartatferd

Selv når SQL Server Machine Learning Services er riktig installert og versjonssamsvarende, kan du nå ytelsesgrenser på grunn av ressursstyring og prosesspooling.Å forstå hvordan oppskytningsplattform- og satellittprosesser oppfører seg er nøkkelen til å levere konsistent latens.

SQL Server oppretter prosesspooler per bruker, per database og per språk for eksterne skriptDet første kallet til sp_execute_external_script etter en periode med inaktivitet fører til at launchpad starter nye satellittprosesser for R eller Python. Denne kaldstarten kan være merkbart treg på servere med høy belastning eller virtuelle maskiner med begrensede innstillinger. Senere kall bruker det oppvarmede bassenget på nytt, slik at den andre og tredje kjøringen er mye raskere.

Hvis forsinkelse ved første anrop er et problem – for eksempel i sanntids scoringsscenarioer – kan du holde bassengene varme ved å kjøre lette skript med jevne mellomrom.Mange team planlegger at et enkelt «no-op» R- eller Python-skript via SQL Agent skal utløses med noen minutters mellomrom, slik at den inaktive oppryddingsoppgaven ikke slår av satellittprosesser.

På SQL Server 2016 Enterprise Edition begrenset tidlige versjoner eksternt skriptminne til rundt 20 % av total RAM.For en server på 32 GB betydde dette at R-kjørbare filer kunne være begrenset til omtrent 6.4 GB per forespørsel. For større modeller eller brede datasett blir dette raskt en begrensning, noe som fører til minneallokeringsfeil eller betydelig sideveksling. Administratorer må gjennomgå gjeldende standardinnstillinger og justere ressursstyringsinnstillingene når komplekse ML-arbeidsbelastninger forventes.

Parallelisme er en annen subtil begrensningNår du kaller Microsoft ML- eller RevoScaleR-biblioteker utenfra SQL Server (f.eks. RGui), selv om den underliggende utgaven er Enterprise, opererer disse bibliotekene ofte i enkelttrådsmodus. På samme måte var det kjente feil i SQL Server 2019 der R-skript som brukte RxLocalPar-kontekster eller den grunnleggende parallellpakken, kunne føre til at SQL Server hang seg opp på grunn av problemer med å skrive til null-enheten i sandkassekjøringen.

Datatype-, koding- og skjemabegrensninger ved kalling av eksterne skript

Datatyper og kodinger er en hyppig kilde til uventet oppførsel når SQL-data sendes til R eller Python via sp_execute_external_script.Ikke alle SQL-typer støttes, og noen støttes bare delvis eller konverteres i bakgrunnen, noe som kan føre til presisjonstap eller ødelagte strenger, spesielt med komplekse strukturer som arrayer i SQL.

Tidligere SQL Server 2017 CU-er hadde sterke begrensninger på numeriske, desimal- og pengetyper for Python-utdataskjemaer.Når det ble kombinert med WITH RESULT SETS og Python, produserte ustøttede typer SqlSatelliteCall-feil og meldinger som indikerte at bare bit, smallint, int, datetime, smallmoney, real og float (pluss delvis char/varchar) var tillatt. Senere CU-er fikset dette, men du må fortsatt være bevisst på hvilke datatyper du eksponerer for eksterne kjøretidsprogrammer.

For R-skript konverteres alle money, numeric, decimal og bigint til Rs numeriske type.Som en konsekvens kan verdier med høy størrelse eller verdier med mange desimaler miste presisjon; pengetyper kan utløse advarsler om at centverdier ikke kan representeres nøyaktig, og bigint overskrider 53-bits heltallsgrensen i R, noe som forårsaker avrunding i de minst signifikante bitene.

Strengkodinger er også viktigeOverføring av Unicode-data lagret i varchar-kolonner kan ødelegge tegn som ikke er ASCII-tegn, fordi SQL Server-kollasjoner kanskje ikke samsvarer med UTF-8-kodingen som forventes av R eller Python. De anbefalte metodene er å bruke UTF-8-kollasjoner som er tilgjengelige i SQL Server 2019+, eller å lagre Unicode-tekst i nvarchar og håndtere konverteringer eksplisitt i skriptet ditt.

Enkelte SQL-funksjoner er helt utenfor grensene for eksterne skriptSpørringer som refererer til Always Encrypted-kolonner eller maskerte kolonner kan ikke mates direkte til R-skript under visse kontekster. Du må kanskje kopiere beskyttede data til midlertidige tabeller uten kryptering eller maskering for analyse. I tillegg kan argumenter som colClasses i R ikke overstyre kolonnetyper i en SQL Server-beregningskontekst. Du må CAST eller CONVERT i T-SQL før du overfører data til R.

Binære nyttelaster har også spesielle reglerNår Rs råtype returneres, må verdien inkluderes i utdatarammen i stedet for å være bundet til en utdataparameter. Bare ett rått utdatasett støttes effektivt. Hvis du trenger flere binære utganger, må du kanskje kalle den lagrede prosedyren flere ganger eller sende data tilbake til SQL via ODBC fra innsiden av skriptet.

Praktiske problemer ved installasjon og utvidelse av Python i SQL Server

Installasjon og utvidelse av Python-miljøet som følger med SQL Server Machine Learning Services er mer begrenset enn en frittstående Anaconda- eller system-PythonMange brukere får feilmeldinger når de prøver å legge til pakker med pip eller sqlmlutils, spesielt på Windows med SQL Server 2019.

På Windows er et vanlig problem etter installasjon av SQL Server 2019 at pip rapporterer TLS/SSL-konfigurasjonsproblemerDen klager over at SSL-modulen ikke er tilgjengelig, selv om du tydeligvis kan kjøre Python. Årsaken er vanligvis manglende OpenSSL DLL-er (libssl-1_1-x64.dll og libcrypto-1_1-x64.dll) i DLL-underkatalogen til PYTHON_SERVICES. Å kopiere disse filene fra Library\bin-mappen til DLL-er og deretter starte en ny ledetekst gjenoppretter vanligvis pips evne til å sende HTTPS-forespørsler.

Noen populære ML-pakker som tensorflow har inkompatible avhengighetskravTensorflow-hjulet kan kreve en nyere NumPy-versjon enn den som er forhåndsinstallert i SQL Servers Python-miljø. Fordi NumPy behandles som en systempakke, kan du ikke oppgradere den gjennom sqlmlutils, så forsøk på å installere tensorflow via den ruten mislykkes. I stedet må du kalle den kjørbare PYTHON_SERVICES-filen direkte med -m pip og oppgradere eller installere pakker i det miljøet, noen ganger etter manuell oppdatering av omdistribuerbare kjøretidsprogrammer som Microsoft Visual C++.

På Linux kan det medfølgende pip-inngangspunktet brytes ut av eskenFor SQL Server 2019 kan kjøring av pip fra /opt/mssql/mlservices/runtime/python/bin krasje med en dårlig tolkefeil som peker til en ikke-eksisterende, eldre ML Server-plassering. Løsningen er å laste ned get-pip.py fra PyPA og kjøre den med den riktige Python-binærfilen under /opt/mssql/mlservices/bin/python/python, som effektivt starter opp pip på nytt for den kjøretiden.

Det finnes også subtile atferder rundt varbinary- og varchar-utdataparametere i Python-skript.Hvis sp_execute_external_script-kallet ditt eksponerer en OUTPUT-parameter av typen varbinary(max) eller large varchar, og du ikke klarer å tilordne en verdi i Python-skriptet, kan BxlServer-komponenten generere feil og slutte å virke. Det sikre mønsteret er å eksplisitt initialisere disse parameterne i Python-koden din, selv om du bare setter dem til en tom streng eller 0x0.

Klassisk SQL + Python-arbeidsflyt med SQLite

Ved å gå bort fra SQL Server-spesifikasjonene, er en svært produktiv måte å lære og prototype SQL-Python-integrasjon på å bruke SQLite med Pythons sqlite3-modul.SQLite lagrer data i én fil, krever ingen separat serverprosess og oppfører seg som en liten relasjonsdatabase med SQL-støtte.

I SQLite er en database bare en organisert fil som lagrer strukturerte data på disken.I likhet med en Python-ordbok tilordner den nøkler til verdier, men den legger til indeksering, effektiv lagring for store datasett og spørremuligheter. Strukturer dreier seg om tabeller (ligner på regneark), rader (poster) og kolonner (felt). I mer formell relasjonell terminologi er dette relasjoner, tupler og attributter.

For å starte kobler du deg til en databasefil med sqlite3.connectHvis filen ikke finnes, oppretter SQLite den. Fra tilkoblingen oppretter du et markørobjekt som fungerer som et håndtak for å utføre SQL-kommandoer og iterere over resultater. Arbeidsflyten er analog med å åpne en fil og lese linje for linje, bortsett fra at du utfører SQL-setninger i stedet for å lese ren tekst.

Å opprette en tabell krever at du angir kolonnenavn og datatyperSelv om SQLite er ganske fleksibel med skriving, hjelper det å definere typer motoren med å velge effektive lagringsformater og indekseringsstrategier. For eksempel kan en enkel tabell for sanger definere en teksttittel og et heltalls avspillingstall. Når tabellen er opprettet med CREATE TABLE, kan du sette inn rader ved hjelp av INSERT og parameterplassholdere (spørsmålstegn) for å binde Python-verdier på en sikker måte.

Bruk av SQL fra Python: INSERT, SELECT, UPDATE, DELETE

SQL tilbyr fire kjerneoperasjoner – INSERT, SELECT, UPDATE og DELETE – som passer fint til Python-kode som fungerer med sqlite3.Hver operasjon manipulerer rader i en tabell, og WHERE-klausulen lar deg målrette mot bestemte poster.

INSERT legger til nye poster i en tabellI Python kaller du cursor.execute med en setning som INSERT INTO Songs (tittel, avspillinger) VALUES (?, ?), og sender en tuppel med parametere. Bruk av plassholdere i stedet for strengsammenkobling unngår SQL-injeksjon og håndterer sitering riktig. Etter inserts kaller du conn.commit for å flytte endringer fra transaksjonen til databasefilen.

SELECT leser data tilbake fra databasen, og filtrerer og sorterer eventuelt resultateneEn enkel SELECT-tittel, som spiller FROM Songs, gjør markøren om til en itererbar over rader. For store resultatsett laster ikke SQLite alle radene inn i minnet samtidig; i stedet gir den dem når for-løkken itererer. Du kan velge alle kolonner med * eller spesifisere et delsett, og du kan bruke WHERE, ORDER BY og LIMIT for å begrense og sortere postene.

DELETE fjerner rader permanent basert på en betingelseEn setning som DELETE FROM Songs WHERE plays < 100 sletter alle sanger med lavt antall avspillinger. Det finnes ingen angrefunksjon, så det er vanlig i veiledninger å slette rader på slutten av et skript for å gjøre eksempler som kjøres på nytt idempotente. Du må legge til etter sletting hvis du vil at endringene skal beholdes.

UPDATE endrer kolonner i eksisterende raderDu spesifiserer tabellen, en SET-klausul med de nye verdiene og valgfri WHERE-logikk. For eksempel påvirker UPDATE Songs SET plays = 16 WHERE title = 'My Way' hver rad med tittel som samsvarer med den strengen. Hvis du utelater WHERE, vil du oppdatere hver rad i tabellen, noe som ofte er en kilde til utilsiktede masseendringer.

Bygge en Twitter-crawler med SQLite og Python

En praktisk demonstrasjon av å blande SQL og Python er en liten Twitter-crawler som lagrer tilstand i en SQLite-databaseSelv om Twitters API-er og retningslinjer endres over tid, er den arkitektoniske ideen fortsatt lærerik: du vil krysse venneforhold, unngå å besøke kontoer på nytt og registrere popularitetsmålinger, samtidig som du kan stoppe og gjenoppta uten å miste fremdrift.

Robotsøkeprogrammet vedlikeholder en tabell over Twitter-kontoer og sporer om hver enkelt har blitt hentet og hvor mange ganger den vises som en venn.Hver rad inneholder kontonavnet, et flagg som indikerer om du allerede har hentet vennelisten, og en teller som viser hvor mange ganger kontoen dukket opp blant andres «venner». Dette lar deg estimere popularitet innenfor det utvalgte nettverket.

Hovedløkken ber brukeren om et Twitter-navn eller en avslutningskommandoHvis brukeren bare trykker Enter, spør skriptet databasen etter den neste kontoen med recovered = 0 og bruker det som neste mål. Deretter kaller det Twitters venne-/liste-sluttpunkt, analyserer JSON-svaret, oppdaterer recovered-flagget for den gjeldende kontoen, og enten setter inn eller oppdaterer hver venn i databasen, og øker vennetellerne etter behov.

Fordi alt er lagret i SQLite, kan du avslutte crawleren og starte den på nytt senereDatabasen fungerer som et varig kø- og tilstandslager. Et separat hjelpeskript kan dumpe innholdet i Twitter-tabellen, slik at du kan inspisere hvilke kontoer som er kjente, hvilke som har blitt besøkt og hvor mange ganger hver av dem har dukket opp som en venn. Dette mønsteret – vedvarende gjennomsøkingstilstand til en relasjonsdatabase – generaliserer godt til andre web- eller API-gjennomsøkingsoppgaver.

Grunnleggende datamodellering: primærnøkler, fremmednøkler og normalisering

Å lagre all Twitter-informasjon i én enkelt tabell fører raskt til problemer med skalerbarhet og redundans.En mer robust tilnærming er å normalisere dataene ved å skille enheter (personer) fra relasjoner (hvem følger hvem) og koble dem sammen via nøkler.

En persontabell bruker vanligvis en heltallsprimærnøkkel som intern identifikatorI SQLite kan du deklarere id INTEGER PRIMARY KEY, og motoren genererer automatisk et unikt heltall for hver innsatte rad. Du inkluderer også en logisk nøkkel, for eksempel Twitter-handlen, merket som UNIK for å forhindre duplikater. Den logiske nøkkelen er det omverdenen bruker, mens primærnøkkelen er det koden din og fremmednøklene refererer til.

En separat følgetabell fanger deretter opp relasjoner ved hjelp av fremmednøklerHver rad inneholder et par bruker-ID-er, vanligvis kalt from_id og to_id (eller lignende), som indikerer at én person følger en annen. Du kan deklarere en UNIK begrensning på kombinasjonen av disse to kolonnene, noe som sikrer at du ikke ved et uhell kan sette inn den samme relasjonen to ganger.

Normalisering – lagring av hver informasjon én gang og referering til den andre steder med nøkler – unngår duplisering, sparer plass og forbedrer ytelsenI stedet for å lagre den samme brukernavnstrengen i millioner av relasjonsrader, lagrer du den én gang i persontabellen og peker deretter til den via heltalls-ID-er. Heltall er raskere å sammenligne og indeksere, noe som blir avgjørende i stor skala.

I Python-kode fører denne designen til vanlige mønstre for å sette inn eller hente brukere og relasjoner.Før du setter inn en relasjon, må du sørge for at begge deltakerne finnes i persontabellen: du bruker en logisk nøkkel, og hvis ingen rad blir funnet, bruker du INSERT og registrerer den siste rad-ID-en som den nye personens ID. Først da kan du SETT INN ELLER IGNORERE en rad i den følgende tabellen som kobler disse ID-ene. Begrensninger og ELLER IGNORER fungerer sammen for å holde dataene dine konsistente uten overdreven manuell kontroll.

Bruke JOIN til å kombinere relaterte tabeller i SQL

Når data er spredt over flere normaliserte tabeller, er du avhengig av SQL JOINs for å rekonstruere den kombinerte visningen du trenger.En JOIN slår sammen rader fra to tabeller basert på samsvarende nøkkelverdier, og oppretter effektivt en virtuell bred rad for hvert treff.

I Twitter-eksemplet kan du se hvem en bestemt bruker følger, eller hvem som følger dem, ved å bli med i tabellene «følgere» og «personer».En spørring som SELECT * FROM Follow JOIN People ON Follow.to_id = People.id WHERE Follow.from_id = 2 henter alle personene som følges av brukeren med intern ID er 2. JOIN-klausulen ber databasen om å matche Follow.to_id med People.id for hver rad, og WHERE-betingelsen begrenser kildebrukeren.

Resultatsettet inneholder kolonner fra begge tabelleneDu kan se de to heltalls-ID-ene fra følgetabellen etterfulgt av den fullstendige personraden (ID, referanse, gjenopprettet flagg) fra persontabellen. Når en bruker følger mange kontoer, får du én kombinert rad per relasjon, som dupliserer noen kolonner fra kildepersonen, men gir deg enkel tilgang til målpersonens attributter.

JOIN-er finnes i flere varianter – INNER, LEFT, RIGHT, FULL – men normaliserte design bruker vanligvis INNER JOIN-er for kjernerelasjoner.INNER JOIN beholder bare radene som har treff på begge sider, noe som stemmer overens med ideen om at en relasjonsrad alltid skal referere til eksisterende personer. Når du feilsøker eller utforsker, kan du SELECT noen få rader fra hver tabell og fra en JOIN-spørring for å bekrefte at modellen oppfører seg som forventet.

Dette relasjonsmønsteret dukker opp overalt: brukere og roller, kunder og bestillinger, produkter og kategorier, innlegg og kommentarer.Når du er komfortabel med å designe tabeller med primærnøkler og fremmednøkler og skrive JOIN-spørringer, kan du modellere og spørre om komplekse domener samtidig som du drar nytte av Python for logikk og analyse på høyere nivå.

Alt i alt betyr det å mestre SQL og Python ikke bare å forstå hvordan man skriver rene spørringer eller skript, men også hvordan kjøretider, drivere, datatyper og ressursgrenser samhandler på tvers av plattformer.Fra å diagnostisere kryptiske maskinlæringstjenestefeil i SQL Server og administrere bibliotekavhengigheter i sandkassede Python-miljøer, til å designe normaliserte SQLite-skjemaer og orkestrere ende-til-ende-analysepipeliner, jo mer flytende du beveger deg mellom database og kode, desto mer robuste og skalerbare blir dataløsningene dine.