>> [MUSIC SPILLE]
DAVID MALAN: Greit, dette er CS50.
Dette er slutten av uken åtte.
Og i dag, starter vi å fylle ut noen brikker
når det gjelder å bygge ting på nettet.
Så husker at på mandag Vi bruker mye mer tid
på PHP, som er denne dynamiske programmeringsspråk som
lar oss utgang, blant annet ting, HTML og andre slike innhold
at vi ønsker å se.
Men vi har egentlig ikke sett på hvordan vi kommer til å lagre informasjon.
Faktisk, kan nesten alle av at det super interessante nettsteder du besøker i dag
har en slags database på baksiden slutten, ikke sant?
Facebook lagrer sikkert massevis av data om oss alle, og Gmail lagrer alle
av e-postene.
>> Og så, mange andre steder er ikke bare statisk innhold som er informative.
Det er faktisk dynamisk på noen måte.
Du gi innspill, oppdaterer den sidene for andre mennesker.
Du får meldinger du sender meldinger, og så videre.
Så i dag, ser vi nærmere på de fundamentet for et prosjekt
at du vil dykke inn i neste uke, CS50 Finance, som
faktisk kommer til å ha deg å bygge noe ikke i C, men i PHP.
En nettside som ser litt noe sånt som dette
som gjør det mulig å kjøpe og selge aksjer som er faktisk
kommer til å trekke på sanntid børsdata fra Yahoo Finance.
Og så til slutt, vil du ha illusjon for deg selv og for brukere
at du faktisk kjøper og selger aksjer og får nesten sanntid
oppdateringer, administrere en portefølje, som alle
kommer til å kreve å ha, til slutt, en database av brukerne.
>> Så, i dine egne ord, spesielt hvis du ikke er
super kjent med datamaskinen vitenskap eller databaser, hva
vet du en database for å være akkurat nå, i ikke-tekniske termer?
Hva er dette?
Hvordan vil du beskrive det til et kollektiv eller en venn?
>> PUBLIKUM: [uhørbart] informasjon [uhørbart]
>> DAVID MALAN: Så, en liste med informasjon, eller en store-- en liste med informasjon
som du kanskje ønsker å lagre om noe, som en bruker.
Og hva gjør brukerne har assosiert med dem?
Hvis du er en bruker på Facebook eller Gmail, hva kjennetegner
at vi alle brukere ha?
Liker, hva som kan være noe av det kolonner i regnearket som vi
hentydet siste gang?
Fordi igjen, kan du tenke på en database
virkelig som en fancy Excel-fil eller Google Regneark eller Apple Numbers-fil.
>> Så, hva synes du om når du tenker på en bruker?
Hva har de?
Hva er det?
>> PUBLIKUM: Et navn.
>> DAVID MALAN: Et navn.
Så hvis navn, som, David Malan ville være navnet på en bruker.
Hva andre gjør en bruker ha?
>> PUBLIKUM: En ID.
>> DAVID MALAN: En ID.
Så, som et ID-nummer, som din Harvard ID eller Yale Net ID eller lignende.
Hva annet kan en bruker ha?
>> PUBLIKUM: Passord.
>> DAVID MALAN: Et passord, kanskje en adresse, kanskje et telefonnummer, kanskje
en e-postadresse.
Så, det er bunter av felt og dette kan liksom komme ut av kontroll
raskt så snart du begynner realisere, oh, la oss lagre dette
og la oss lagre og datt.
>> Men hvordan gjør vi faktisk gjøre det?
Så igjen, den mentale modellen å ha for i dag som vi
dykke inn i selve SQL, Structured Query Language,
er en database som ser ut som dette.
Det er bare rader og kolonner.
Og du kan forestille Google Spreadsheets eller hvilket som helst antall andre programmer.
Men hva er nøkkelen om MySQL, som er den databaseprogramvare vi kommer til å bruke,
det fritt åpent available-- Facebook bruksområder
det og en rekke andre websites-- databasen lagrer ting relasjonelt.
Og en relasjonsdatabase betyr bare en som bokstavelig
lagrer dataene i rader og kolonner.
Det er så enkelt som det.
>> Så selv noe sånt som Oracle som du kanskje har generelt hørt om
er en relasjonsdatabase.
Og under panseret, det lagrer data i rader og kolonner.
Og Oracle belaster deg en mye penger for å gjøre det,
mens MySQL avgifter du ingenting for det samme.
Så, er SQL kommer til å gi oss minst fire operasjoner.
Muligheten til å velge data, slik som lese data, sette inn, slette og oppdatere data.
Med andre ord, de er egentlig de fire nøkkeloperasjoner
som kommer til å tillate oss å endre ting i disse rader og kolonner.
>> Verktøyet som vi bruker i dag spesielt å lære SQL og å leke med den
er igjen kalt PHP MyAdmin.
Det er web-basert verktøy.
Total tilfeldighet at det er skrevet i PHP.
Men det kommer til å gi oss en grafisk brukergrensesnitt, slik at vi faktisk kan
lage disse rader og kolonner og deretter snakke med dem via kode.
Så, la oss nå begynne å hva jeg tror er ærlig
form av moroa prosessen med bygge bakenden av nettsteder,
de delene som brukerne ikke se, men sikkert bryr seg om,
fordi det er heller data er i gang.
Så, i likhet med C og en litt mindre som PHP,
SQL, eller en database som støtter SQL, har minst disse datatypene
og bunter av andre.
Røye, VARCHAR, INT, BIGINT, Desimaltall, og DATETIME.
Og det er en hel haug med andre funksjoner,
men la oss gjøre dette ved å måte å faktisk eksempel.
>> Jeg kommer til å gå inn i CS50 IDE der, på forhånd, jeg har logget inn
og jeg har også besøkt en URL for dette verktøyet kalles PHP MyAdmin.
Og i oppgavesettet syv, vil vi fortelle deg nøyaktig hvordan du får til dette grensesnittet
også.
I øverste venstre hjørne, merke det står forelese.
Og det betyr bare at på forhånd, jeg opprettet
en tom database kalt foredraget som ikke har noen regneark i det ennå.
Det er ingen rader og kolonner.
Fordi den første ting vi kommer til å gjøre
er begynne å lage en tabell som kommer til å lagre våre brukere.
>> Så, bokstavelig talt over her til høyre, er jeg
kommer til å fortelle databasen Jeg vil ha en tabell kalt Brukere.
Så, dette er som den filen som jeg ønsker å lagre alle mine data i.
Og hvor mange kolonner?
Vel, la oss holde det enkelt for nå.
Jeg vil bare lagre som en brukernavn og et navn på en bruker.
Vi vil begynne i det små.
Så, jeg vil ha to kolonner totalt.
Og jeg kommer til å gå videre og klikk OK.
Og så, for disse kolonner, hva jeg skal
å do-- hvis denne internett cooperates-- all right,
så vi kommer til å prøve det igjen.
Jeg kommer til å lage en tabell kalt Brukere med to kolonner, klikk på Go, OK.
Nå har vi det veldig fort.
Takk, veldig godt gjort.
Greit, så hva gjør vi ønsker disse kolonnene å bli kalt?
>> Så, man kommer til å bli kalt Brukernavn.
Så alt jeg ser her-- og grensesnittet ærlig blir litt stygg slutt,
når du begynner å skrive i alle disse dataene.
Men hva er hyggelig er at slags paradoksalt nok, jeg skaper kolonner,
men verktøyet har tåpelig lagt dem ut i rader
slik at jeg kan konfigurere disse kolonnene.
Så, det er to blanks der under Navn.
Og en av disse feltene jeg ønsker å kalles brukernavn,
og det andre feltet jeg vil kalle navn.
>> Og nå må jeg velge datatyper for disse tingene.
Så, mens i Excel og Google Spreadsheets,
Hvis du ønsker en kolonne, du bokstavelig talt bare skriver navn eller brukernavn, trykk Enter.
Kanskje du gjør det med fet skrift bare for klarhet, men det er det.
Du trenger ikke oppgi typer av kolonner.
Nå i Google Spreadsheets eller Excel, du kan angi hvordan dataene er gjengitt.
Du kan gå til Format-menyen, og du kan spesifisere vise dette som dollartegn,
viser dette som et flyttall.
>> Så det ligner i ånden til at det vi er i ferd med å gjøre,
men dette er faktisk kommer til å tvinge dataene til å være en bestemt type.
Nå, selv om et øyeblikk siden jeg sa det er bare noen få datatyper,
det er faktisk en hel masse, og de er
i varierende grad av spesifisitet.
Og som en digresjon, du kan selv gjøre fancy ting
som lagrings geometrier innsiden av en database.
Du kan lagre ting som GPS-koordinater
og faktisk finne, matematisk, punkter som er nær andre.
Men vi kommer til å holde dette super enkelt
og gå opp til her, alle de såkalte strengtypene.
>> Så, her er en liste over en hel haug av alternativer.
Røye, VARCHAR, TINYTEXT, MEDIUMTEXT, LONGTEXT.
Og det er litt overveldende.
Og dessverre, noe paradoksalt nok til C,
en CHAR er virkelig ikke en CHAR.
Hvis du angir i en database at datatype er CHAR,
det betyr at ja, det er en CHAR, men det er ett eller flere tegn.
Og du må spesifisere hvor mange tegn du vil.
Så, hva er en typisk lengde for et brukernavn?
Er det en grense typisk?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: 16 kanskje?
Noe sånt.
Du vet, tilbake i dag, det pleide å være åtte.
Noen ganger er det 16, noen ganger det er enda mer enn det.
Og så gjør ikke dette bety gi meg en CHAR.
Dette betyr at jeg må spesifisere lengden av feltet,
og nå kan jeg si noe sånt som 16.
Og det er en trade off her.
Så får vi se på et øyeblikk at dette betyr en,
hver brukernavn må være 16 tegn.
Men vent litt, M-A-L-A-N. Hvis det er brukernavnet mitt og jeg bare bruker fem,
hva ville du foreslå at databasen å gjøre for de andre 11 tegn på at
Jeg har reservert plass til?
Hva vil du gjøre?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Ja, bare gjøre dem alle null.
Gjør dem mellomrom.
Men sannsynligvis null, slik at en Mange backslash nuller.
Så, på den ene siden, har vi nå sørget for at brukernavnet mitt
kan være mer enn 16 tegn.
Og baksiden av det er at hvis jeg hadde en veldig langt navn
eller ville ha en veldig lang brukernavn som noen av dere
Gutta kan ha i at høyskole eller på Yale.edu, kan du ikke har en.
Og så faktisk, hvis du har noen gang er registrert for et nettsted
og du får skrek til å si passordet ditt er for lang
eller brukernavnet ditt er for lenge, det er rett og slett fordi en programmerer, når
konfigurering av sin database, besluttet at dette feltet vil
være lenger enn denne lengden.
>> Greit, så hva om vi fortsette å nevne?
Hvor lenge bør en typisk menneskelig navn være?
Hvor mange tegn, 16?
Jeg gjetter vi kunne finne noen i dette rommet
der ved hans eller hennes første pluss siste Navnet er lengre enn 16 tegn.
Så, hva er bedre enn det, 17?
18?
25?
Større?
30?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: 5000, oh my God.
Så, det er sannsynligvis en anstendig øvre grense, skal vi si.
Og her vi slags har å foreta en vurderingssak.
Liker, det er ingen riktig svar her.
Infinite er ikke helt mulig, fordi vi er slutt
kommer til å have-- vi er kommer til å gå tom for minne.
Så har vi å gjøre en vurderingssak på enkelte punkt.
>> Meget vanlig vil være, for eksempel, til use-- og la meg spesifisere CHAR her
som before-- 255 var bokstavelig øvre grense på denne databasen programvare
År siden.
Og så, en masse mennesker ville bare si, fine.
255 er grensen.
La oss bare bruke det maksimale.
Og dette er ganske latterlig.
Som, hvis du skriver noens nevne for 200 pluss tegn,
som en litt latterlig.
>> Men, husk at ASCII er ikke det eneste systemet for tegn.
Og så, spesielt i en Mange asiatiske språk
hvor det er tegn vi kan ikke uttrykke på keyboard som min amerikanske
tastatur, noen tegn faktisk ta opp 16 bits i stedet for åtte bits.
Og så, dette faktisk er ikke alle som urimelig
at vi trenger mer plass hvis vi ønsker å passe
større tegn enn de aller USA sentriske de vi har en tendens til å diskutere.
Så, trenger vi noen øvre grense.
Jeg vet ikke hva det beste er, men 255 er generelt en vanlig en.
25 føles lav.
16, 32 føler lav.
Jeg vil feile på siden av noe høyere.
Men det er en trade off, som alltid.
Hva er det kanskje innlysende trade off for å reservere 255 tegn
for alle navn i databasen min?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Hva er det?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Det er en mye minne, ikke sant?
M-A-L-A-N. Jeg har bare kastet bort 250 tegn bare for å lagre navnet mitt
defensivt, bare i tilfelle noen i klassen har et virkelig langt navn.
Det virker som en utilbørlig kompromisset.
>> Så viser det seg at SQL, denne databasen språk,
faktisk støtter noe kalt VARCHAR, eller variabel CHAR.
Og dette er slags fint i at dette lar deg spesifisere ikke en fast
bredde, men snarere en variabel bredde.
Og mer spesifikt, en maksimal bredde av feltet.
Så betyr dette at et navn kan ikke være mer enn 250 tegn,
men det kan sikkert være færre.
Og databasen skal være smart.
Hvis du putter i M-A-L-A-N, det er bare kommer til å bruke fem,
kanskje seks byte for like en etterfølgende null karakter,
og ikke bruke en ekstra 249 eller 250 bytes unødvendig.
>> Så, dette virker som jeg burde har begynt med denne historien.
Men det er alltid en avveining.
Så, på den ene siden et brukernavn jeg har angitt å være hardkodet på 16,
og kanskje det var ikke høyre samtalen, kanskje det
er, men hvorfor ikke bruke VARCHARs for alt?
>> Det finnes for en grunn.
Hvorfor ikke bruke VARCHARs for hvert felt hvis lengde du ikke kjenner på forhånd
hvis det ser ut til å være en god ting, ikke sant?
Bruk bare så mye plass som du må opp til denne grensen?
>> PUBLIKUM: Tregere.
DAVID MALAN: Speller?
PUBLIKUM: Gjør det saktere?
DAVID MALAN: Å, det er tregere.
Bra, det er nesten alltid svaret, ærlig.
Liker, hva er kompromisset?
Det enten koster mer plass eller det koster mer tid.
Så, i dette tilfellet, kan det være tregere.
Hvorfor?
>> PUBLIKUM: [uhørbart] bestemme [uhørbart].
>> DAVID MALAN: Good.
Så, kanskje du husker fra selv PSED5, leker med din tilnærming
i ordlisten, hvis du må allokere minne dynamisk eller holde
vokser en buffer, som faktisk kan være treg.
Hvis du må ringe malloc under panseret og kanskje
det er hva MySQL gjør, så sikkert som kunne være tilfelle.
Og hvis du tror måte tilbake til PSet-- eller
uker to, når vi gjorde ting som binære søk eller lineær søk,
en av de fine tingene om hvert ord i en database eller i hvert ord i en kolonne
å være nøyaktig den samme lengde, selv hvis en hel haug av disse tegnene
er tomme, er at du kan bruke tilfeldig tilgang på dataene dine, ikke sant?
>> Hvis du vet at hver Ordet er 16 tegn unna,
du kan bruke pekeren aritmetikk, så å snakke, og gå til oss 16, 32, 48, 64,
og du kan bare hoppe øyeblikkelig hjelp aritmetikk
til noen av ordene i databasen.
Mens hvis det er en VARCHAR, hva gjør du i stedet har å gjøre?
>> [Telefonen ringer]
>> Hvis det er en VARCHAR, du kan ikke bruke random access.
Det du må se etter eller gjøre?
Yeah?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Look gjennom whole-- spor
gjennom hele listen på jakt etter det, mest sannsynlig?
Hva slags spesiell verdi?
PUBLIKUM: [uhørbart]
DAVID MALAN: Looking for null terminatorer
at avgrense separasjon av ord.
Så igjen, en hestekreftene, og det er ingen riktig svar.
Men det er her, særlig når brukerne kommer til å være mange
og belastningen på serverne, de antall personer som bruker det blir høy,
disse er faktisk nontrivial beslutninger.
Så kan vi la disse som dette, men La oss bla ned over til høyre
her.
Nå er det et par kolonner der vi må gjøre en vurderingssak.
Er det fornuftig å la en brukers navn, en brukers brukernavn eller en brukers
navn, for å være null?
Det vil si, bare blank.
Føles litt meningsløse, så jeg er ikke kommer til å sjekke disse boksene.
Men det viser seg i en databasen, kan du si,
noen kan eventuelt ha denne verdien.
Denne kolonnen har ingen å faktisk være der.
>> Nå er det denne rullegardinmenyen.
Og legg merke til jeg er fortsatt i den første raden der,
så jeg snakker om brukernavn nå.
Og det viser seg at en database, i motsetning til en enkel bare regneark,
har kraftige funksjoner kalt indekser.
Og en indeks er en måte å fortelle database på forhånd at jeg den menneskelige
er smartere enn deg.
>> Jeg vet hva slags spørsmål, velg eller sette inn eller slette eller oppdatere,
at koden min kommer til å ende opp med å gjøre på denne databasen.
Jeg ønsker å lese en masse data.
Jeg ønsker å sette inn en masse data.
Jeg ønsker å stadig slette en masse data.
Hvis jeg vet at jeg kommer til å være tilgang til et felt som brukernavn mye,
Jeg kan preemptively fortelle database, jeg vet mer enn deg,
og jeg ønsker å resolusjon som du bør indeksen dette feltet.
Hvor indeksering et felt eller en søyle betyr at databasen på forhånd
bør låne noen ideer fra, som, uke fire og fem og seks fra CS50
og faktisk bygge opp noe som en binær søk
tre eller noe vanligvis kalles en B tre
at du ville lære i en klasse som CS124
ved Harvard, en algoritmer klasse, eller hvilket som helst antall av andre steder.
>> Databasen og smart folk som gjennomførte det
vil finne ut hvordan du lagrer det bordet av informasjon
i minnet slik at søk og andre operasjoner er super rask.
Du trenger ikke å gjøre det.
Du trenger ikke å implementere lineær søk eller binære søk
eller fusjonere sort eller utvalg sort, noe av det.
Databasen gjør det for deg hvis du forteller det preemptively å indeksere dette feltet.
>> Og du kan se også, det er noen andre egenskaper
vi kan fortelle databasen for å håndheve.
Hva kan det bety hvis jeg velger Unique fra denne menyen, bare intuitivt?
Yeah?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Ja, brukernavn må være unike.
Er dette en god ting eller en dårlig ting for en database, for et nettsted med brukere?
Bør brukernavn være unik?
Ja, sannsynligvis.
Hvis det er det den feltet vi bruke til å logge inn,
du egentlig ikke ønsker å folk ha den samme følelsen eller samme brukernavn.
Så kan vi ha database håndheve at så
som nå i min PHP kode eller hvilket som helst språk, Jeg trenger ikke å, for eksempel, sjekk
nødvendigvis gjør dette brukernavnet eksisterte før jeg la noen registrere?
Databasen vil ikke la to personer som heter David eller Malans registrere i dette tilfellet.
>> Og som en digresjon, selv om dette menyen bare lar deg velge en,
en unik indeks er en som er indeksert for super rask ytelse,
men det også håndhever unikhet.
Og vi vil komme tilbake til hva to andre mener om en liten stund.
I mellomtiden, hvis jeg går til min andre rad, noe som
er brukerens navn, skal jeg spesifisere at navnet skal være unike?
Nei, fordi du kunne sikkert have-- det er ikke to David
Malans i dette rommet, mest sannsynlig.
Men hvis vi velger et annet navn, vi kan sikkert ha kollisjoner.
>> Tenk tilbake til hasj tabeller og lignende.
Så, vi absolutt ikke ønsker for å gjøre navnefeltet unikt.
Så, vi bare kommer til å forlate at så dash, dash, dash, ingenting.
Og jeg kommer til å forlate alt annet alene.
Faktisk har de fleste av disse feltene Vi trenger ikke å bry seg om.
Og når jeg er klar til å lagre dette, hvis internett samarbeider,
Jeg klikker på Lagre, og veldig, veldig, veldig sakte gjør databasen bli frelst.
Og nå er jeg tilbake til dette grensesnitt, som riktignok
er overveldende ved første øyekast.
Men alt jeg kommer til å gjøre er å klikke på ordet Brukere på venstre.
Jeg kommer til å gå opp her, og klikk Brukerne, og som standard, det
har henrettet noen SQL, men mer om det i et øyeblikk.
Her er bare en oppsummering av hva jeg gjorde.
Og ikke å bekymre deg for at du ser omtale av latin og svenske her.
De er bare standard innstillinger, fordi MySQL opprinnelig,
eller PHP MyAdmin, en av de to som skjedde å være skrevet av noen svenske folk.
Men det er irrelevant i vårt tilfelle her.
>> Greit, så hvorfor er alt dette interessant?
Det viser seg, kan jeg sette inn data inn i en database ved å skrive kode.
Og jeg gå videre og i min fil her, er jeg
kommer til å gå videre og late som dette er kablet til at databasen, som
det er ikke i øyeblikket, men det vil være når vi kommer til oppgavesettet sju.
Og jeg kommer til å gå videre og utføre en funksjon kalt spørring,
som vi vil gi deg i oppgave satt sju distribusjons kode, som
tar minst ett argument, som er bare en streng.
En streng med SQL-kode.
I så fall er du i ferd med å lære å skrive Structured Query Language.
>> Hvis jeg ønsker å sette inn en ny rad i min database fordi noen har sendt inn
et skjema for å koden min, ville jeg bokstavelig talt skrive INSERT INTO brukere følgende
felt: brukernavn, komma, navn, verdiene,
og nå trenger jeg for å sette inn noe som Malan, og sitat,
unquote 'David Malan. Og nå selv for de som ikke kjenner SQL,
hvorfor jeg bruker apostrof innsiden av denne grønne string?
Hva kan være årsaken her?
>> Legg merke til jeg er co-mingling to språk.
Søket er et PHP-funksjonen, men det tar et argument.
Og det argumentet må selv være skrevet på et annet språk kalt
SQL, Structured Query Language.
Så, alt som jeg har nettopp fremhevet her
er dette språket kalles SQL.
Så, hva skjer med de enkle anførselstegn, akkurat som en rask tilregnelighet sjekk?
Gå videre.
De er strenger.
Så, sitat, unquote Malan og sitat, unquote David Malan er strenger.
Og bare tenker intuitivt nå, vite hva du vet om C og PHP,
hvorfor gjorde jeg ikke dette, som jeg vanligvis brukte doble anførselstegn for strenger?
Hvorfor gjorde jeg ikke ønsker å gjøre det?
Yeah?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Nettopp.
Fordi jeg allerede bruker anførselstegn på vei
utsiden av argumentet til PHP-funksjonen,
Jeg ville bare forvirre tolk.
Det vil ikke vet, disse gå sammen?
Har disse gå sammen?
Så, jeg veksler i stedet.
>> Eller jeg kunne gjøre noe som dette, backslash sitat eller backslash sitat.
Oppriktig, som bare begynner å får veldig uleselig og stygg.
Men det ville oppnå det samme resultat også.
>> Så, hvis jeg skulle utføre dette spørring nå, la oss se hva som skjer.
Jeg kommer til å gå videre nå og heller enn kjøre PHP-koden, som
er hvor du vil spille i oppgavesettet syv,
Jeg kommer til å gå i stedet for å PHP MyAdmin.
Og jeg manuelt gå å gå til kategorien SQL,
og la meg zoome inn på grensesnittet.
Og jeg kommer til å lime inn i det jeg nettopp skrev.
Og fargekoding har endret litt nå,
bare fordi programformater ting litt annerledes.
Men legg merke til at alt jeg har gjort er jeg har sagt, setter inn brukere.
Jeg har spesifisert, da, i et komma separert parentes liste de to
felt som jeg ønsker å sette inn, og da har jeg bokstavelig talt sa verdier
etterfulgt av en annen paren, og deretter de to verdiene
Jeg ønsker å plug-in, og nå for godt mål,
Jeg skal sette et semikolon på slutten.
Så dette er ikke C. Dette er ikke PHP.
Dette er nå SQL, og jeg lime den inn i denne web-basert grensesnitt som er
bare tenkt å la meg, så snart jeg klikker Go,
utføre dette søket på databasen kjører innsiden av CS50 IDE.
>> Så dette er bra.
Legg merke til at sa en rad satt inn, gikk super fort,
0,0054 sekunder for å sette inn disse dataene.
Så, det høres ganske sunt.
Det formatert min spørring for meg her bare for å se det
i form av fargekodede versjon.
Men nå hvis jeg klikker Bla, legge merke til at selv
selv om det er mye rot på skjermen, har mitt bord nå to rader.
>> Så, la meg gå videre og gjøre en annen.
I stedet for dette, la meg gå til fanen SQL igjen.
Og denne gangen skal jeg sette inn noe sånt Rob og hans navn skal være Rob Bowden.
Bowden.
La oss klikker du Lagre.
Oops, heller gå.
>> Klikk Bla gjennom igjen, og Nå merker jeg har to rader.
Så dette er bare en måte mer komplisert måte å åpne opp Google Spreadsheets
og bare å skrive en rad i en kolonne.
Men hva er nøkkelen er at vi nå har syntaksen
som å skrive koden slik at til slutt, kunne vi faktisk
gjøre noe og dette.
Husker at PHP støtter super globale variabler.
>> Hva er innsiden av dollar logg strek GET i PHP?
Vi tok en titt på en eller to enkle eksempler.
Og i PSet6, husker du har hallo dot PHP som bruker denne variabelen.
Hva går inn der?
Eller hva er det?
En litt høyere.
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Det er en snø frø av array, som
er bare en fancy måte å si en array som har sentrale verdiparene.
Og tastene er ikke numerisk.
De er ord eller strenger.
Og spesielt hva er de sentrale verdiparene?
Hvor kommer de fra?
Sorry?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Nei?
Hvor de nøkkelen verdi-par kommer fra?
Si igjen?
Igjen?
Er jeg den eneste som hører noe?
>> [LAUGHTER]
>> Det er riktig, ja?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Ja, de kommer fra søkestrengen.
Så, hvis du spole tilbake i tid for å når vi har spilt med Google
og vi har gått til Google.com slash søk spørsmålstegn q lik katter,
hvis jeg skulle treffe på Enter, og hvis Google ble implementert i PHP,
PHP-kode som Google skrev ville ha tilgang til dollartegn
underst GET innsiden av som er en nøkkel kalt Q og en verdi
kalt katter som det da kan bruke pleide å gjøre en faktisk søk ​​med.
>> Så, faktisk, hva jeg kommer til å gjøre nå er å gå tilbake til min PHP-kode
at du vil igjen se mer av i PSet7.
Og i stedet for å koble i hardt kodede verdier som
ser ikke ut som en veldig dynamisk nettside,
Jeg kommer til å gi deg en teaser av hva din faktiske koden ville gjøre.
Du ville sette seg i to spørsmålstegn som dette.
Jeg vet ikke hva brukernavnet er.
Jeg vet ikke hva Navnet kommer til å være,
men jeg vet jeg kan få dem dynamisk.
>> Så, hvis koden vi skriver nå er koden kjører på Googles servere,
eller om dette er hei dot PHP, som kommer med PSet6,
Jeg kommer til å passere inn spørringen funksjon
akkurat som printf, to andre argumenter.
GET, sitat, unquote brukernavn, og GET, sitat, unquote navn.
Og nå, legge merke til hva generell struktur er her.
Jeg har fått til venstre side av samtalen,
Denne funksjonen kalles spørring i PHP.
Jeg har fortsatt som en først argument, bare en tekststreng.
>> Men at tekststreng er skrevet på et språk som kalles SQL.
Og ærlig talt, det er ikke et stort språk.
Vi kommer bare til å snakke om det formelt i dag, egentlig.
Og deretter i oppgavesettet syv, det er relativt
noen funksjoner som vi er kommer til å utnytte.
Spørsmålstegnene, men mener plugge inn en verdi her, og plugg i en annen valuta
her.
Og legg merke til, jeg har utelatt hva fra hele quote-- jævla
it rundt sitatet markerer denne gangen.
Jeg har utelatt sitatet tegn rundt spørsmålstegn,
beklager, denne gangen rundt.
>> Så, hva er fint om dette spørsmålstegn funksjon som
PHP har en tendens til å støtte, Ruby og Python og andre språk,
Dette betyr bare plugg i noen verds her og vet du hva?
Du regne ut om du vil bruke apostrof eller doble anførselstegn.
Ikke bry meg med dem intellektuelt uinteressante detaljer.
Men, pass på at det er riktig slik at koden min er slutt
operasjonell og trygg, som vil ha en mening før lenge.
>> Nå, hvor mange argumenter totalt, bare for å være klar, er spørsmålet funksjonen tar?
Alle som ønsker å stemme for mer enn to?
Tre?
Jada, hvorfor?
Hvorfor tre?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Nettopp.
Den første delen er strengen.
Det andre argumentet er dollartegn underst GET brakett brukernavn.
Og den tredje argumentet er samme, men bare navnet.
Så med andre ord, nå hvis jeg hadde et webskjema
som måtte tekstfelt, en for brukerens brukernavn,
en for hans eller hennes navn, bare som du ville se på en nettside
når du registrerer deg for noen nettside, kan dette
være koden på baksiden slutten som faktisk gjør innsetting nå
inn i databasen.
>> Nå derimot, la oss spole frem.
Anta at en bruker er nå logge inn og du vil
å skrive PHP-kode som sjekker om den personen som nettopp logget inn
er faktisk en bruker, kan du bruker ganske enkel syntaks.
Du kan si SELECT, la oss si Star, hvor stjerne betyr alt.
Jeg vet ikke hva jeg vil, så bare gi meg
alle kolonnene fra tabellen kalt brukere der, og dette er hyggelig.
Velg støtter hva som er kalt et predikat, som er
som en måte å kvalifisere hva du vil.
Der brukernavn er lik sitat, unquote Malan.
Så også her, jeg har innebygd inne argumentet
til en PHP-funksjon, en linje av SQL-kode.
Og at SQL-kode dette tid er bokstavelig talt går
for å søke etter sitat, unquote Malan.
>> Nå det er ikke alle som nyttig, så jeg kommer til å hoppe over det
og jeg kommer til å sette bort dette tipset fra Brady, og gå
og plug-in i stedet et spørsmålstegn her.
Så, bare for å være klar, hva bør mitt andre argument
bli hvis noen har bare logget inn og jeg lurt å sjekke om han eller hun er faktisk
en bruker?
PUBLIKUM: [uhørbart]
DAVID MALAN: Yeah.
Jeg hører dollartegn strek GET sitat, unquote brukernavn.
Og som bør komme tilbake til meg noen av radene i min database
som har et brukernavn av Malan.
Nå forhåpentligvis, jeg kommer til å komme tilbake null hvis Malan har aldri vært her,
eller en hvis han har.
Jeg skal ikke komme tilbake to eller tre eller fire.
Hvorfor?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Jeg sa unik, ikke sant?
Enkel grunn.
Fordi jeg sa at det er nødt til å være unik, bare logisk,
du kan bare ha null eller ett Malans i denne spesielle databasetabell.
Nå som en side, bare så du har sett det, selv om jeg fortsetter å bruke GET
og selv om PSet6 bare brukt Get, kan du sikkert ha POST.
Og minner om at Post er en annen teknikk for å sende inn informasjon
fra et skjema, men det vises ikke i nettadressen.
Det er litt mer sikker sikkert for ting som brukernavn og passord,
som PSet7 vil i virkeligheten innebære.
>> Så, la oss gjøre dette i PHP MyAdmin og se hva som skjer.
Jeg kommer til å gå til fanen MySQL.
Og legg merke til at standardverdien for PHP MyAdmin, bare for å prøve å være nyttig,
er å velge stjernen fra brukerne hvor man.
Vel, er man alltid sant, så dette har dum effektiv
for bare å velge alt.
Men jeg kommer til å være litt mer pedantisk og manuelt
skriv ut SELECT stjerne fra brukere.
>> Nå teknisk, kan du oppgi navnet på bordene.
Det er sjelden at du må, men legg merke til disse er ikke
normale sitater på amerikansk tastatur.
Dette er den såkalte accent grave, hvilken er vanligvis på venstre hånd
hjørne av tastaturet.
Men det er sjelden at du vil faktisk trenger å bry deg med det,
så jeg skal bare hoppe over dem uansett.
Så nå, la meg gå videre og treffe gå.
Og hvor mange rader bør jeg få tilbake når jeg velger stjerne fra brukerne?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Antall rader, sikker.
Men hvor mange i denne betong story akkurat nå?
To, fordi det var meg og det var Rob.
Så, hvis jeg klikker OK, jeg ser visuelt at Jeg har fått tilbake, ja, to rader.
Det er mye rot på skjermen, men jeg ser bare to rader.
Derimot, hvis jeg gjør dette igjen og gjøre SELECT stjerne fra brukere, der brukernavn
lik sitat, unquote Malan, nå hvis jeg klikker Go,
Jeg bare kommer til å få tilbake en rad.
Og til slutt, hvis jeg gjør noe som dette, antar
at jeg ikke bryr seg om få alt,
som er slags meningsløst nå, fordi det er bare to kolonner.
Det er ikke som jeg har valgt en enorm mengde data.
Anta at jeg gå videre og trenger SELECT navn FROM
brukere, der brukernavn tilsvarer Malan, hva er fint om SQL ærlig,
er at det egentlig bare gjør det du ber den om.
Det er ganske kortfattet, men du bokstavelig talt bare fortelle det hva du vil gjøre.
Velg navn fra brukere der brukernavn lik Malan.
Og det virkelig er så eksplisitt.
Så nå hvis jeg treffer Go, hvor mange rekker jeg kommer til å komme tilbake?
En, fordi det er bare Malan, forhåpentligvis.
Eller null hvis han ikke er der, men en maksimalt.
>> Og hvor mange kolonner vil jeg komme tilbake?
Hvor mange kolonner?
Denne gangen, jeg bare går å få en fordi jeg ikke
Velg stjernen, som er alt.
Nå er jeg velge bare navn, så jeg bare få tilbake en kolonne og en rad.
Og det ser liksom hensiktsmessig latterlig, bare ser super
liten som dette.
Så, hva er det egentlig som skjer?
Når du utfører et SQL spørring ved hjelp velger,
hva du får tilbake fra databasen
er som en midlertidig tabell med rader og kolonner, kanskje,
men det utelater noe som ble faktisk ikke valgt av deg.
Så, er det som om noen hadde en stor regneark med alle elevene
registrert for noen studentgruppe, og du sier,
gi meg alt av freshman som har registrert for vår studentgruppe, hva
din kollega i studentgruppe kan gjøre
er de bare kunne levere du hele regnearket.
Det er som å si velger stjerne.
Og det er litt irriterende hvis du bare ønsket freshman.
Og så, hvis du i stedet sa, Velg stjerne fra database tabell
hvor året er lik sitat, unquote freshman,
det er som om din venn i studentgruppen
bokstavelig markert og kopierte bare freshman rader,
limt dem inn i en ny Google Regneark eller en Excel-fil,
og ga deg tilbake resulterer bare fil.
Det er alt som kommer på konseptuelt her.
>> Så til slutt, kan vi gjøre noen ganske fancy ting
ved å lagre ting som brukernavn og passord og lignende.
Men, det viser seg, skal vi gjøre en litt annen måte enn dette.
Det er ikke så smart å bare lagre et brukernavn og et passord.
Noen tidligere, tror jeg her nede, foreslo en ID.
Nå en ID kan være som en Harvard-ID eller Yale netto ID,
men det kan være enda enklere i vår database tilfelle.
Og ja, den felles saken er å ha en annen kolonne.
Og jeg kommer til å gå videre og redigere mitt bord.
Og hvis du leke deg med dette grensesnittet for PSet7,
vil du se at du kan sjekke denne knappen her og legge
et felt ved begynnelsen av tabellen.
Og nå hvis jeg klikker Go, kommer det til å gi meg en av disse formene
fra tidligere.
Jeg kommer til å legge til et felt som heter ID.
Og jeg kommer til å gjøre det til en numerisk type.
>> Jeg har en hel haug av verdier for tallverdier.
Jeg skal bare velge en INT og Ikke bekymre deg om de ulike størrelsene.
Jeg trenger ikke å oppgi en lengde eller en verdi,
fordi det kommer til å være 32 biter uansett.
Attributter, fikk vi ikke se før.
Noen interesse i en hvilken som helst av disse menyalternativer denne gangen?
For en INT?
Hva gjorde du foreslår?
Nei?
Har noen av disse fornuftig?
Yeah.
Ja, usignert, ikke sant?
>> Vanligvis til hvis vi skal gi alle et unikt nummer, som
er der denne historien er går jeg egentlig bare vil ha
en person å ha nummer lik null og en og to og tre og fire.
Jeg trenger ikke å forholde seg til med negative tall.
Det virker bare som utilbørlig kompleksitet.
Jeg ønsker fire milliarder mulige verdier, ikke fire milliarder mulige verdier,
så jeg bare doblet kapasitet på min INT.
Som en side, hvis du ønsker å forholde seg dette til noe sånt som Facebook,
tilbake i form av dagen min da Facebook først kom ut,
Jeg tror hva de var bruker i sin MySQL database
å lagre en brukers identifikator, var bare en INT.
Men selvfølgelig, det er mye av virkelige mennesker i verden.
Det er mye av falske Facebook kontoer i verden.
Og så til slutt, Facebook flyt på størrelse med et INT, en fire milliarder
verdi.
Som er grunnen, hvis du ser rundt, og det finnes nettsteder
som kan fortelle deg hva din unike ID er.
Og hvis du velger aldri et brukernavn i Facebook, vil du se din unike ID.
Jeg tror det er profilen dot PHP spørsmålstegn ID lik noe.
Det er nå noe som en stor INT, eller en lang lang om du vil,
som er en 64-bits verdi eller noe tilsvarende.
>> Så, selv i den virkelige verden gjør disse problemstillinger slutt noen ganger rolle.
Og det viser seg her, hvis jeg er å gi alle mine brukere en unik ID,
Jeg ønsker å være super eksplisitt og minimal gjøre dette feltet unikt.
Men det viser seg at det er en stykke nomenklatur i dag også
det er en primærnøkkel.
Hvis du utformer en database bord og du vet på forhånd
at en av kolonnene i tabellen bør og vil entydig identifisere rader
i tabellen, vil du spesifisere det og fortelle databasen,
dette er min primærnøkkel.
Det kan være duplikater i andre felt,
men jeg fortelle databasen som dette er mitt primære, min viktigste feltet,
som er garantert å være unik.
>> Nå, dette synes overflødig.
Jeg er nå foreslår at vi legge til, ved å klikke Lagre her,
et felt called-- og jeg kommer å gå videre og klikk AI,
vi vil komme tilbake til det i et øyeblikk, Spar.
Jeg foreslår nå at mitt bord se slik ut.
Jeg har en INT felt kalt ID, en CHAR felt som heter brukernavn,
en VARCHAR felt kalt navn, men ID, hvis det er primær og derfor unikt,
hvorfor gjorde jeg bare kaste bort tid å introdusere det
er effektivt en andre unik felt som heter ID som er en INT?
>> Brukernavn, husker, var allerede unik, sa vi.
Så bare logisk, trenger du ikke noen database erfaring til grunn
gjennom dette, hvorfor kanskje jeg har introdusert
en INT som min unik identifikator også?
Hva er det som sier dette-- igjen?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Random tilgang er enklere, hvorfor?
>> PUBLIKUM: [uhørbart]
DAVID MALAN: Ja, det er bare tilgang til tallene.
Så, hvis du tenker på dette virkelig er en tabell, slik som en matrise,
nå har jeg unike identifikatorer at jeg kan hoppe rundt.
Og bedre enn det som fremdeles er at hvor stor er en INT kommer til å bli igjen?
32 bits eller fire byte.
>> Hvor stor er brukernavnet mitt kommer til å være?
Maksimalt?
16 bytes.
>> Så, hvis du virkelig omsorg om ytelsen til koden,
tenker tilbake til PSet5, ville du foretrekke for å søke etter en fire byte verdi eller en 16
byte verdi, ikke sant?
Det er virkelig så enkelt som det.
Du må gjøre fire ganger så mye arbeid å søke etter brukernavn fordi disse
er 16 bytes.
Så må du bokstavelig talt sammenligne alle 16 bytes å være
at ja, dette brukernavnet jeg vil.
Mens det for en INT, kan du gjøre det med bare fire bytes.
>> Og som en side for de interessert i maskinvare,
det viser seg at du får plass til noe sånt en INT eller en 32-bits verdi i noe
kalles et register i en datamaskin CPU, noe som betyr at det er super,
super rask, selv på laveste nivå av datamaskinens maskinvare.
Så, det er bare fordeler rundt.
Så, hva betyr dette?
Faktisk, når du designer en databasetabell, nesten hele tiden
skal du ha ikke bare de dataene du bryr deg om,
men også noe sånt en unik identifikator
fordi dette skal la oss gjøre andre ting.
Og la oss reise over ett problem her.
>> Anta at brukerne har ikke bare brukernavn og navn,
men de har også ting som byer og stater og postnummer, minst
her i USA.
Så, jeg kommer til å gå videre og bare raskt si,
gi meg tre kolonner ved enden av bordet.
Og dette kommer til å være by, dette kommer til å være stat,
og dette kommer til å være Zip.
>> Nå by, hva datatyper bør dette være, kanskje?
VARCHAR?
Jeg vet ikke hva lengste navn byen er.
Et eller annet sted i Amerika, det er sannsynligvis noen latterlig langt ord,
så la oss bare gå med 255, noe historisk eller vilkårlig.
Staten, hva du ønsker å gjøre?
Vurderingssak, ikke sant?
Hva er kanskje den mest effektive?
Hvor mange tegn?
Kanskje bare to, hvis vi kan komme unna med å gjøre nettopp,
som, MA for Massachusetts, og så videre.
Så, jeg kommer til å gå en CHAR verdi av to.
>> Postnummer er en interessant ett.
Vi er her i 02 138, slik at foreslår vi bør bruke det?
Det er en INT, ikke sant?
INT, INT, kort?
Kort sagt vil fungere.
Nei?
CHAR eller fem, men jeg vil ha en INT.
Hvorfor presse tilbake på en INT?
Tale meg fra dette.
Hva er dumt om en INT, min idé?
Yeah.
>> PUBLIKUM: Ta opp mer minne.
>> DAVID MALAN: Ta opp mer minne.
Fire bytes, men du er foreslår et postnummer
som fem bytes eller noen var som en røye, som føles som eh, det er egentlig ikke
tilfelle.
>> Vel, morsom historie.
År siden, da jeg pleide å bruke Microsoft Outlook for e-posten min,
Jeg fikk til slutt ønsket å bytte til Gmail.
Og så, jeg eksportert alle mine kontakter fra Outlook som en CSV-fil.
Kommaseparert verdier, som nettopp mente jeg
hadde alle mine venners navn og sist navn og telefonnumre og postnumre
og alt dette.
Og så jeg gjorde feil for å åpne den opp
i Excel, som er en regnearkprogram som
forstår CSV-filer som vi har sett.
Men så, jeg må ha truffet, som, Kommando eller kontroll S på ett punkt.
Og Excel tilsynelatende på den tiden hadde en funksjon der enhver tid det
så et tall, den prøvde å være nyttig.
Og hvis det tallet startet med nuller, det ville bare bli kvitt dem.
Hvorfor trenger du fører nuller på heltall?
De er meningsløst, matematisk.
De er ikke meningsløst i US Postal-systemet.
Så, jeg har hatt i årevis, til denne dagen, jeg fortsatt
har venner som når sjeldne tilfelle at jeg trenger noen er
løse disse dager, Jeg vil fortsatt se at jeg
har en venn i Cambridge, Massachusetts, 2 138.
Og det er irriterende hvis du er prøver å sortere av programma
generere konvolutter eller bare notere det ned.
Og det er på grunn av denne grunn, Jeg valgte feil datatype.
Så, jeg elsker ideen din.
La oss bruke et CHAR-feltet.
Fem tegn, unntatt Det er et hjørne tilfelle.
Hvis du fortsatt sende mail, noen ganger zip koder i disse dager,
de er, liker, pluss fire.
Så trenger vi en bindestrek og deretter vi trenger fire tall.
Så for å være ærlig, det kunne gå mange forskjellige måter.
>> For nå kommer jeg til å holde det enkelt og jeg er bare
kommer til å si at det er en five CHAR verdi, og vi er
kommer til å hoppe over hele dashbordet pluss fire.
Men disse er de typer avveininger.
Og du kan tenke på samme problemene som oppstår
med telefonnumre eller andre felt.
>> Og nå, dette er faktisk en tåpelig veien å gå ned.
Anta både Rob og jeg og Hannah og Maria og [? Davon?] Og Andy
og andre i staben alle lever i Cambridge, Massachusetts, 02138.
Dette faktisk føler meg dum som jeg er legge til min brukere bord, by, stat,
og glidelås.
Hvorfor?
>> PUBLIKUM: [uhørbart]
>> DAVID MALAN: Si igjen?
PUBLIKUM: [uhørbart]
>> DAVID MALAN: De er alltid kommer til å gå sammen, ikke sant?
Når det viser seg, vi pleide å tenke dette var tilfellet før vi uttømmende
søkte hele USA, og viser seg at det
er noen uoverensstemmelser der flere byer har
samme zip, som er merkelig.
Men, hvis vi stiller for nå at 02138 er alltid Cambridge, Massachusetts,
hvorfor i all verden ville du lagrer i databasen Cambridge og MA og 02138
for meg og for Hannah og for Rob og for [? Davon?] Og for andre som bor
her i Cambridge, er det helt overflødig.
>> Vi bør komme unna med bare lagring av hva?
Bare postnummer.
Men så, hvis vi lagrer bare postnummer, jeg vil, sannsynligvis,
for mitt nettsted for å vite hvor 02138 er.
Så, jeg trenger en annen tabell.
Og det er OK.
Og faktisk, er dette en av de designprosesser med å utforme tabeller
at du vil gjøre i PSet7 samt hvor du ønsker å faktor ut felles data.
Akkurat som vi har vært facto ut felles kode og factoring ut felles
stiler fra CSS, her også i databasen,
hvis jeg trenger bare 02 138 til entydig identifisere noen hjemby,
lagrer ikke Cambridge, Mass for hver darn bruker i tabellen.
>> I stedet har en egen tabell som heter Glidelåser som skal ha hva kolonner?
Sannsynligvis en ID-feltet, bare fordi, for prinsippene vi snakker om nå.
Sannsynligvis en zip-feltet for 02138.
Og da trolig hva andre kolonner?
By og stat, men bare har én rad for 02138, én rad for 02 139,
én rad for 90210.
Og det er bokstavelig talt alle postnumre jeg vet.
>> Så nå, hva kan du gjøre?
Dette er problematisk, fordi nå har jeg fått to tabeller.
Så, brukerne mine er for det meste over her, men deres bystaten informasjon finnes
her.
Så viser det seg med SQL, det er faktisk en måte å bli med informasjon,
og du vil se dette i PSet.
>> Men det viser seg at du kan gjøre noe som dette.
SELECT stjerne fra brukere, BLI glidelåser ON Brukerne dot zip tilsvarer glidelåser dot zip.
Som er litt ordrike, riktignok, men dette er bare
betyr å velge alt fra prosessen med å ta mitt brukere bord
og min glidelåser bord.
Bli med dem på den ene felt har de i kolonnen.
Så, bokstavelig talt gjøre noe som dette, og gi meg tilbake
en ny midlertidig tabell som er bredere, som er større,
som har alle kolonner fra dem begge.
Og det, ganske enkelt, ville være syntaks for å gjøre noe som dette.
>> Så, det er dette på forhånd, men det kommer
å være andre design avgjørelsene du har å gjøre, ikke bare med indekser
men også å kjøre inn i utfordringene.
Faktisk, det er en utfordring i noen database design
der noen ganger to folk kanskje vil for å få tilgang til de samme radene i databasen
tabell.
Så, dette er noe som vi vil møter i PSet7 også.
>> Men jeg tenkte jeg skulle se på en angrep som er mulig i SQL.
Hva er noen av de problemer som kan oppstå?
Så møter du dette i PSet7.
Og vi fortelle deg direkte hva koding løsning på dette problemet er.
Men hvis du tar et høyere nivå klasse, spesielt i operativsystemer,
du kommer til å støte en sak av atomicity,
problemet med å prøve å gjøre flere ting på en gang
uten avbrudd.
>> Og jeg tenkte jeg skulle introdusere dette Ideen til PSet7 med en metafor
at jeg lærte meg selv i Margo Seltzer sin CS164 operativsystemer
klasse år siden.
Anta at du har en av disse dorm kjøleskap i din hybel eller hus,
og du har en ekte forkjærlighet for melk.
Og så kommer du hjem fra klassene en dag, du åpner kjøleskapet.
Å, faen.
Det er ingen melk i kjøleskapet.
Så lukker du kjøleskap, låse døren, låse dorm,
gå rundt hjørnet til CVS, komme på linje,
og begynne å sjekke ut for litt melk.
Og det kommer til å ta en stund, fordi de jævla selv kassen
tellere ta en evighet å bruke uansett.
Så i mellomtiden, kommer romkameraten hjem.
Han eller hun virkelig liker melk også.
De kommer inn i hybel, åpner kjøleskapet, oh, darn det.
Det er ikke mer melk.
>> Så, han eller hun også går rundt hjørnet.
Men nå, siden det er som to eller tre eller fire CVSes nærheten,
de måtte gå til en av de ulike de på torget.
Og så nå, et par minutter senere, dere begge
komme hjem og ugh, verste problemet noensinne.
Nå har du for mye melk fordi det kommer til å gå sur.
Og du liker melk, men du vet egentlig ikke liker melk.
>> Så nå, dette var en dyr feil fordi dere begge
gjort en beslutning basert på tilstand av noen variabel som
var i ferd å bli endret av deg,
initiativtaker kommer til å få melk.
Så, hva er kanskje et menneske løsning på det problemet?
PUBLIKUM: [uhørbart]
DAVID MALAN: Legg igjen en kommentar, ikke sant?
Alltid la et notat, hvis du er kjent med at showet.
Ja, det er to av oss.
Så, la alltid et notat, eller bokstavelig talt låse kjøleskapet
med noen form for hengelås eller noe over toppen sånn.
Men det er faktisk kommer til å være Hovedproblemet med database design,
spesielt når du kan ha flere nettlesere, flere bærbare datamaskiner,
flere brukere alle prøver å oppdatere informasjon på en gang.
Særlig følsomme opplysninger som finansiell informasjon,
der med en aksjehandel nettsiden som du vil bli bygget,
hva om du ønsker å sjekke hvor mye penger du har og hvis du har nok,
kjøpe noen aksjer?
>> Men hva om noen andre som har en felles konto med deg
er samtidig prøver å kjøpe noen aksjer?
Så, er han eller hun sjekker saldo, både for deg
få tilbake den samme Svaret er det ingen melk.
Eller begge av dere kommer tilbake svaret, du har $ 100 i kontoen.
Begge du prøver å ta avgjørelsen å kjøpe en andel av litt selskap lager.
>> Og nå, hva skjer?
Du har to aksjer?
Du har ingen aksjer?
Problemer som kan oppstå.
Så vil vi møte det.
SQL-injeksjon angrep, heldigvis, er noe vi vil hjelpe deg med,
men disse er atrociously vanlig i disse dager fortsatt.
Så, dette er bare et eksempel.
Jeg gjør ingen påstander om at Harvard PIN-systemet er
sårbare for denne spesielle angrepet.
Vi har prøvd.
Men, du vet at vi har et felt som dette.
Og Yale netto ID har en lignende ser skjermen i disse dager.
Og det viser seg, at kanskje PIN-systemet er implementert i PHP.
>> Og hvis det were-- det er not-- de kan ha kode som ser slik ut.
De har to variable.
Gi meg brukernavn og passord fra stillingen super global variabel
som vi snakket om tidligere.
Kanskje Harvard har en spørring som SELECT stjerne fra brukere
der brukernavn er lik som og passord tilsvarer det.
Og legg merke til at jeg bare plugge den i å bruke
krøllete brace notasjon fra den andre dag, som betyr å bare plugge inn en verdi
her.
Jeg bruker ikke den spørsmålstegn teknikk.
Jeg har ikke noen andre eller tredje argumenter.
Jeg er bare bokstavelig talt konstruere strengen selv.
>> Problemet er imidlertid at hvis noen liker en scroob,
som er en referanse til en film, logger på med noe sånt som dette,
og jeg har fjernet prikkene som vanligvis dekke opp
passord, hva om han er spesielt skadelig
og hans passord kanskje er 12345, per filmen heter "Spaceballs"
men han kritisk typer en enkelt sitat etter fem,
så bokstavelig ordet eller i rommet, og deretter sitat,
unquote en er sitat en, Men legg merke til han utelatt hva?
Han utelatt sitatet til høyre og han utelatt sitatet til venstre.
>> For hvis dette angriper scroob sin antagelse
er at folk som skrev dette PHP-koden ikke var så lyse,
kanskje de bare har noen enkelt siterer rundt interpole
av en variabel i klammeparentes?
Og så kanskje, kunne snill han av fullføre sin tanke
for dem, men på en måte som vil å la ham hacket inn PIN-system.
Med andre ord, antar at dette er den koden
og vi nå plugge i hva scroob skrevet.
Og det er rødt, fordi det er ille.
>> Og den underliggende tekst er det han har skrevet i,
scroob kunne lure Harvard server til å bygge en SQL-spørring
strengen som ser ut som dette.
Passord tilsvarer 12345 eller en er lik en.
Resultatet av dette, logisk, er at dette vil logge scroob
i Hvis hans passord er 12345 eller hvis en er lik
en, noe som er selvsagt alltid er sann, som betyr scroob alltid får inn.
>> Og så, måten å fikse dette, som i mange tilfeller
ville være å skrive mer defensivt.
Å bruke noe sånt som vår Selve søket funksjon, som
du vil se i PSet7, hvor vi kobler noe som spørsmålstegn her.
Og skjønnhet spørring funksjon som vi
gi deg er det beskytter mot disse såkalte SQL-injeksjon angrep, der
noen lure koden inn injisere sin egen SQL-kode.
Fordi hva spørringen funksjon vi gir deg faktisk vil gjøre,
hvis du bruker spørsmålstegn syntaks og en andre og en tredje argument her
er hva gjorde det legge til innspill som brukeren gitt?
De backslash siterer.
>> Så slipper det noe potensielt farlige tegn.
Dette ser rart nå, men det er ikke sårbar
fordi det ikke endre logikken lenger
fordi det hele passord er nå et enkelt sitat som ikke er det,
faktisk, scroob passord.
Så har det vært noen vitser om dette i løpet av årene.
Så dette var et bilde tatt av noen geek på en parkeringsplass
hvorved du kanskje vet at enkelte byer og stater prøver å skanne lisens
plate til å fakturere deg eller billett hvis du går gjennom uten, som,
E-Z Pass ting.
Så, denne personen antas at kanskje folk skrive e-Z Pass system
var ikke så lyse, og kanskje de bare bundet sammen for en streng,
slik at han eller hun kunne ikke skadelig ikke bare fullføre sin tanke,
men faktisk utføre en dårlig kommando, som vi ikke har nevnt ennå,
men du kan sikkert gjette.
At i tillegg til å slette og sette inn og oppdatere og velge,
det er også et nøkkelord som heter drop, som bokstavelig talt sletter alt
i databasen, noe er spesielt ille.
>> Vi kan zoome inn på dette hvis det er litt vanskelig å se.
Dette, nå er en kjent tegneserie det er fantastisk flink nå
og forståelig.
>> [LAUGHTER]
>> Ja, kult.
Kind of geeking ut.
Så disse er altså SQL-injeksjon angrep.
Og de er så lett å unngå ved å bruke den riktige koden eller de riktige bibliotekene.
Og du vil se i PSet7, det er Derfor gir vi deg spørringen funksjon.
Så, et par teasers at vi trodde vi skulle
gi deg her i vår værende minutter sammen.
Så, som du husker fra uke null, vi introduserte disse to lyspærer som
er hyggelig, ikke bare fordi de er pen og er fargerike,
men fordi de støtter noe kalles en API, et program
Programming Interface Og i CS50 så langt, vi har
hovedsakelig fokusert på GET og POST, men det viser seg
det er andre HTTP verb som PUT.
>> Og faktisk, dette var et lysbilde fra uke null
der hvis du skriver kode som sender a la PSet6 en HTTP-forespørsel som
ser slik ut med denne del av teksten på bunnen, som kalles JSON,
eller Javascript Object Notation at vi skal snakke om neste uke,
du kan slå på eller slå av eller endring fargen på lysene som de.
Så hvis CS50 har også i tillegg til noe av disse lyspærer her i New Haven
Hvis du ønsker å låne dem for siste prosjekter,
også noen Microsoft Band, som er som
klokker som du bærer rundt håndleddet som på samme måte har en API, slik at du
kan skrive din egen programvare for dem.
>> Vi har en konto med Apples iOS-koden slik
at hvis du har en Apple Watch eller en iPhone eller en iPad eller en iPod,
du kan skrive kode som faktisk kjører på dem.
Vi har en hel haug av Arduinos, som er
bitte små datamaskiner uten tilfeller, i hovedsak,
at du kan koble til via USB, vanligvis til din egen Mac eller PC,
skrive kode som kjører på disse fysiske enheter som ofte har sensorer på dem
slik at du kan samhandle med den virkelige verden.
Vi har en hel haug av Leap Motion enheter,
som er USB-enheter for Mac og PCer, her og igjen, i New Haven.
Og hvis du kobler den til Mac, du faktisk kan kontrollere datamaskinen
ved å skrive programvare som via infrarøde stråler,
finner ut hvor menneskehender er, selv uten å røre tastaturet.
Vi tenkte vi skulle dele en rask glimt på dette, for eksempel.
>> [MUSIC SPILLE]
Så har vi en hel haug av disse tingene,
Også kalt Myo armen band som du satt over underarmen
og deretter kan du kontrollere den virkelige verden eller den virtuelle verden som dette.
>> [MUSIC SPILLE]
Eller, vi har også noen Google Papp, som er bokstavelig talt, som,
en pappeske du kan sette på din ansikt, men raset i telefonen i det
slik at du setter glasset på Telefonen veldig nær øynene.
Og Google papp er ganske billig på $ 10 eller $ 20.
Og det har lite objektiver som litt av skift
bildet på skjermen for menneskelig øynene for å gi deg en følelse av dybde
slik at du faktisk har en 3D- miljø foran deg.
Vi har også noen Samsung Gear, som er den dyrere versjon av denne,
men som kan gli i et tilsvar Android-telefon, og gi deg en illusjon
of-- eller gi opplevelsen virtuell virkelighet.
Og i våre to siste minutter, vi tenkte vi skulle prøve å gjøre dette.
Hvis jeg kan projisere hva Colton har her bare for å skjerpe appetitten,
la meg gå videre og kaste opp på storskjermen her.
La meg drepe lysene.
Colton, ønsker du å gå videre og satt på cella for et øyeblikk
og kom over til midt på scenen?
Og ønsker du å project-- dette er hva Colton ser.
>> Nå, Wi-Fi i her er ikke så sterk for denne enheten
at dette er super overbevisende, men Colton er bokstavelig talt
i denne magiske futuristiske sted.
Han ser bare ett bilde.
Du ser hans venstre og høyre øye at hjernen hans er å sy sammen
i en tredimensjonal miljø på ansiktet hans.
Han har nettopp valgt et menyvalg her.
Og så igjen, har han på seg dette headsettet med en Samsung telefon på det som er
trådløst prosjektering til vår overhead.
Nå er du på Mars, tror jeg?
COLTON: Jeg tror det.
Jeg er ikke sikker [uhørbart].
[LAUGHTER]
>> DAVID MALAN: Slår ut Mars har disse menyene.
>> COLTON: [uhørbart] noen kule steder hvis vi ønsker å gå to--
>> DAVID MALAN: Hvor skal vi ønsker å gå?
>> COLTON: [uhørbart]
DAVID MALAN: Og la oss se hvor Colton tar oss nå.
COLTON: [uhørbart]
>> DAVID MALAN: Så, det er så mange forskjellige steder du kan ta deg selv.
Det er FAPIs via som du kan skrive spill eller interaksjoner som
drives, til slutt, på telefonen.
Så, du egentlig bare skriver en mobiltelefon app.
Men takket være programvaren og grafikkfunksjonene,
nå Colton er i denne bitte liten hytte.
Og med fare for overveldende oss selv,
Colton og jeg vil holde rundt for mens på slutten av klassen her i dag
Hvis du ønsker å komme opp og spille.
Og vi vil bringe dem tilbake neste uke også.
Uten videre om og men det er det for i dag.
Vi sees neste uke.
>> [MUSIC - Ragga TWINS, "dårlig menneske"]