>> Greit.
Så, uten videre, SQL, Structured Query Language.
Så, har du sannsynligvis brukt dette på minst i CS50, kanskje i CS165,
kanskje i din egen personlige prosjekter.
Og hva betyr SQL la deg gjøre, i en SQL Server mer generelt?
Yeah?
[Hørbar Remark]
OK, det var veldig sikret måte å si det.
Ja. Så det gjør du lagre data
og enda viktigere tillater du til å søke etter data.
Og dette er et skritt fremover
fra å bruke noe enklere som en CSV, ikke sant.
Comma Separated variabler.
Lignende verdier.
Tilsvarende kan du spare informasjon én rad
i en tekstfil.
Men hva er ulempen av en CSV-fil for lagring av data,
selv om du effektivt få rader og kolonner fra det?
Yeah.
>> Du trenger ikke 'har samme organisasjon
effektivitet [uhørbart].
>> Du har ikke den samme organisasjon effektivitet.
Hva mener du?
>> Vel, som [uhørbart] har som primær [uhørbart].
>> OK. Yeah.
>> Det er en relasjonsdatabase du kan ha flere databaser
koblet til hverandre i svært spesifikke måter.
>> OK. Bra.
>> Det er [uhørbart] å sette en CSV.
>> Og la meg finpusse litt terminologi.
Så flere tabeller innenfor en database, sikker,
og som går utover det som du kan gjøre med bare ett CSV.
Men egentlig begrensningen med CSV jeg vil hevde er
at ineffektiviteten i det hele tatt.
Det er veldig lett å layout.
Men hvis du ønsker å gjøre en spørring, hva er kjøretiden
i alle utvalgsspørring på en CSV-fil?
Jeg mener det er stor gammel [uhørbart], riktig, fordi i verste fall
de steg helt nederst.
Selv om du hadde sortert hele CSV-fil, hvis du ikke vet
at forhånd, vel, du fortsatt kommer til å ha
å søke på hele greia.
Så, blant de tingene vi kommer til å få
fra å bruke en faktisk database ved hjelp av et språk
som SQL er vi kan spørre det, og vi kan på forhånd
som databasedesignere spesifisere hva er felt
som ble sannsynligvis kommer til å ha spørsmål om slik at folk
på MySQL eller Microsoft eller Oracle,
den som har gjort databasen du bruker kan gjøre alt
av hardt arbeid finne ut, OK,
gitt en million av disse IDS.
Hvordan kan vi layout - dem ut i minnet?
Noen slags tre strukturere kanskje,
slik at når du gjør faktisk utføre Select,
det er noe som er logaritmisk eller logaritmisk
av logaritmisk i tid heller enn faktisk devolving
til noe lineær.
Så vi fikk en masse ytelse på den måten.
Og vi kan også lagre mye mer data lettere 'føre til at SQL
Server er vanligvis lagret i RAM selv om deler
av det kan bli lagret på disken og du sikkert vet nå
at RAM er generelt raskere enn disker,
så det er en god ting.
Og vi kan også håndtere samtidighet mye bedre.
Hvis du har tatt 165 eller 161, du vet at hvis to mennesker prøver
å gjøre det samme på en gang på et system,
dårlige ting kan generelt skje.
Så blant de andre funksjonene vi kan få hvis vi utformer våre tabeller
på riktig måte er bedre støtte og sikkerhet
når det kommer til samtidighet.
Så, to personer i to deler
av verden ved hjelp av samme hjemmeside, hvis de begge prøver
å kjøpe noe på samme tid, er det for ikke å gå
å gå inn samtidig.
Noe de ville bli serialisert av noen andre enn vår egen -
noen andre enn oss selv.
Databasen vil gjøre det for oss.
Så når det er enkleste form,
SQL lar oss spør en relasjonsdatabase.
En relasjonsdatabase er en som har en
eller flere tabeller i det typisk.
Og hvis dette er et Litt uvant,
du kan egentlig bare tenke av dette som Excel eller tall
eller Google-regneark.
Den har bare rader og kolonner og vanligvis toppen av hvert
av de radene har et navn for det.
Så dette kan være ID kolonnen, navnet kolonnen,
adresse kolonnen og så videre.
Og så kan du ha flere slike tabeller hvis du vil
å begynne å legge ut ulike typer data.
Men du husker kanskje minst fra CS50 at vi prøvde
å gi deg en GUI-baserte verktøy [uhørbart]
å administrere databasen din.
Det ble kalt phpMyAdmin.
Så det er bare en tilfeldighet at det ble skrevet i PHP, egentlig,
men det var bare en web-basert front end til en database.
Og via de ulike kategoriene og koblinger, kan du begynne
å konfigurere en database for deg selv.
Men et godt verktøy for å begynne å blir litt mer komfortabel
med, er også kommandolinjeklient.
Så, hvis du bruker CS50 Appliance eller egentlig bruker noen makro PC
som har en kommandolinje MySQL klienten, kan du også gjøre det liksom
av gamle skolen, som dette.
Som en digresjon MySQL-prosjektet, i det minste den åpne source versjon
av er det nå heter MariaDB for ulike grunner til at du kan lese
opp på Wikipedia, men det er den samme programvaren,
det er det samme syntaks og så videre,
ganske mye den samme kodebasen.
Og så når jeg er på dette spør jeg kan nå samhandle
med min database mye manuelt.
Så sak, la meg gå videre
og bare åpne opp et terminalvindu.
Jeg skjedd å bruke CS50 Apparatet, men du kan gjøre dette
på de fleste helst system i som du fikk rett
programvare installert.
Og jeg kommer til å gjøre MySQL-u for brukernavn John Harvard
på dette systemet,-p for et passord som jeg skal skrive
i litt mer sikkert ved å treffe på Enter.
Nå er jeg bedt om det.
Jeg kommer til å skrive crimson i CS50 Appliance
og nå ser jeg egentlig at den samme skjermen.
Men det er kommandoer nå at vi kan begynne å skrive
som viser databaser, og som kommer til å vise meg alt
av databasene som jeg har allerede opprettet i systemet,
ganske mye den samme listen du ville se i phpMyAdmin.
Det er et par andre som informasjon skjema og test,
som hvis du rote rundt CS50 Appliance, vi skjuler noe
av disse lavere nivå tabeller
men de har vært der hele denne tiden.
MySQL har faktisk lavt nivå egenskaper som brukernavn
og passord for databasen seg selv, ikke for din søknad
at du kan være kjører på toppen av den.
Så på forhånd, i dag, jeg skapte et par databaser,
hvorav den ene som kalles courses50.
Odds er noen av dere har brukt CS50 selvfølgelig shopping verktøy,
noe som er en stor grensesnitt for registraren kurskatalog.
Og dette er faktisk en fin datasett for å snakke om 'årsak,
ett, vi er liksom alt åpenbart kjent med kurs
og instruktører og møte steder og all slags
av vanlige ting av universitetet,
men det har også fått noen interessante muligheter
for design.
Så vi tenkte at vi skulle bruke den oppfatningen av en kurskatalog
og et kjøpesenter verktøy som en eksempel hele dag for å sortere
av rammen noen av utformingen avgjørelsene vi må gjøre.
Så la oss starte der.
Anta at jeg faktisk ønsket for å representere den super enkleste
selvfølgelig handle verktøy.
Og den enkleste verden Jeg kan forestille seg og man er
hvor det er kurs og det er instruktører.
Og la oss anta å skyld diskusjonen
at hvert kurs har minst et navn.
Så la oss begynne å skissere dette ut.
Jeg kommer til å bruke phpMyAdmin akkurat som en bekvemmelighet
slik at vi ikke trenger å skrive ut alle forespørsler manuelt.
Men her er jeg i min courses50 database.
Hvis ukjent med dette, det vil være veldig lett når du dykker
i til ditt eget prosjekt Hvis du ønsker å bruke den.
Jeg kommer til å opprette en tabell kalt Kurs
og jeg kan bare tenke av en felt
for nå, navnet på et kurs.
Jeg kommer til å gå videre og si gi meg en kolonne.
Nå, som du husker du får et grensesnitt som er litt
som dette.
Og den andre opp ærlig av phpMyAdmin er at det liksom
selv-instruere og at via nedfellsmenyen, kan du sortere
av se hva din mulige design beslutninger er.
Så jeg kommer til å gi hver selvfølgelig et navn.
Det er navnet på denne kolonnen.
Og hva med datatypen?
De fleste av dere skal vite at minste noen av disse datatyper
fra tidligere erfaring.
Hva er passende for kursnavn?
Sharon?
>> Varchar.
>> OK, varchar som er Variable Char.
Og hva gjør det bety mer teknisk?
[Hørbar Remark]
OK. Så det er en streng.
Og Var aspektet av det innebærer hva?
Variabel. Men hva betyr det?
Yeah?
[Hørbar Remark]
Nettopp. Så det er en variabel antall tegn
i strengen opp til en viss maksimum.
Så her er vår første design beslutning.
Vi har faktisk må bestemme hvor mange byte maksimalt
å tildele til hver slik streng.
Generelt sett, vil du slags ikke gjøre det for lite,
Ikke gjør det for stor 'Føre opplagt
hvis for liten du er bare kommer til å starte avkorting data
og du vil miste informasjon.
Og hvis det er for stor, du er bare liksom fortelle databasen
å forvente og å optimalisere for mer data
enn det kan faktisk aldri få.
Så hva er en rimelig følelse nummer etter navnet på et kurs?
60? OK, så 60 år.
Det virker ganske rimelig
så lenge er det ingen unntak til denne.
Det er egentlig ingen hard, fast regel.
For å være ærlig, for historiske årsaker mye
folk vil velge 255 'Føre for årene som var liksom
av maksimal standard bruker 8 byte - 8 biter som disken din.
Jeg hadde mer [uhørbart] kan bruke krefter 2
men det er liksom irrelevant.
Så vi kan gå med 60 år.
Det virker fornuftig så lenge
som vi til slutt ikke angre på det Fordi det er en øvre grense.
Nå antar det motsatte beslutningen var fattet,
ikke variable tegn, men bare røye feltet.
Så i motsetning til C og C + +, røye betyr ikke at man røye
og databaser som betyr som regel et fast antall
tegn i en streng.
Hva ville være oppsiden og / eller Ulempen med min velger 60
for en char-feltet, i stedet for varchar?
Dette er nøyaktig den første typen av avgjørelsen du må gjøre
ved inspeksjon [fonetisk] ut av prosjektet med dine partnere.
Ja, Sharon igjen.
[Hørbar Remark]
Bra. Så hvis navnet er færre
enn 60 så du kaster bort uansett at deltaet er
mellom 60 og faktiske lengde.
Så det føles bortkastet, flere bytes enn du trenger.
Men hvorfor virker det finnes?
Det må da være noen oppside.
Yeah?
[Hørbar Remark]
Jada. Så noen ganger du kanskje vet det fast antall
tegn som 10 siffer for et telefonnummer for eksempel.
Men hvem bryr seg, som for eksempel hvorfor ikke bare si 11 uansett
eller hvorfor ikke si 60 likevel med varchar?
Hvilken fordel får vi ved å vite og å utforme
for et fast antall tegn?
[Hørbar Remark]
Du er på rett spor.
Så det er optimalisering men det er virkelig av - ja?
[Hørbar Remark]
OK. Bra. La oss fokusere på den siste delen.
Så indeksering.
Så det viser seg hvis du vet på forhånd at alle
av feltene skal å være 60 tegn,
du kan egentlig tenke på dette kolonne i Excel database
som har veldig rett, venstre begrunnet
og høyrejustert kanter
fordi hver kolonne er 60 tegn brede.
Det betyr at denne strengen er 60 tegn unna
fra denne strengen, 60 tegn unna fra denne ene
og dette, og denne.
Så akkurat som tilbake når du lærte C, hadde du random access
i verden av arrays, samme ideen her.
Hvis spalten din er representert kun ved hjelp av fast lengde tegn,
Du kan effektivt index tilfeldig til 60 eller 120 eller 180
og du kan få på individuelt strenger mye raskere.
Så hvis stedet, hadde spalten din en rett venstre kant så å si
men en veldig robust høyre kanten til kolonne
fordi du kanskje har 10 tegn,
15 tegn, 5 tegn.
Så dette er også en byttehandel.
Og noen ganger bare gjennom prøving og feiling
og eksperimentering kan du finne
ut hva som egentlig rett anropet er, men disse er de typer
spørsmål som bør gå
gjennom deres sinn og / eller tabeller når det gjelder tid
å designe databasen.
Så, ikke nødvendigvis riktig svare, men du bør
i det minste har en viss setning eller to i tankene
å ta backup uansett beslutning du gjør.
OK.
Så la oss holde rulling i instruksjonene her
som er phpMyAdmin UI.
Så, standardverdien for et navn, bør jeg spesifisere
at det skal være ha en standardverdi på null?
Hva tror du?
Kan et kurs har en null navn?
Bare føles rart, ikke sant?
Jeg kan ikke tenke på noen ikke navngitte kurs ved Harvard.
Og kanskje det er noen obskure hjørnet saken
hvor et kurs er gitt en rekke
og professoren har ikke valgt et navn for det, men -
Jeg mener, til pokker med det,
som la oss ikke engang gidder å støtte det.
Jeg vil si i interesse av en fin ren database,
La oss presisere at du ikke kan har en standardverdi på null.
Alternativt kan vi gjøre noe som untitled kurs
som ikke er ulikt med Mac OS og Windows gjør
når du oppretter en mappe for eksempel,
men det som gjør litt mer fornuftig
slik at menneske se noe.
Vi snakker om en back-end database formodentlig
for kurskatalog.
Så jeg gjør ikke egentlig selv liker tanken på å gi det
i untitled løypenavn
siden det er egentlig ikke kommer til å hjelpe noen.
Så la oss la dette som ingen, noe som betyr at når du setter inn
inn i denne databasen, må du å gi hver selvfølgelig et navn
som føles litt renere til meg.
OK.
Så rulle videre, sortering.
Dette har bare å gjøre med tegnsett og whatnot
Hvis du noensinne har sett nevner av svenske
i phpMyAdmin det er 'Føre folket
som skrev phpMyAdmin var svensk.
Er at PHP eller er det MySQL?
En av de to, I glemte avfeiende.
Men det er historiske årsaker
men du kan uttrykke alle karakter på engelsk
at du kunne med svenske så det er i stor grad et ikke-tema.
Den CS50 Appliance er skjønt brukes - konfigurert til å bruke UTF-8,
slik at generelt bør ikke komme opp for deg.
Attributter.
Så ingen av disse er virkelig relevant her.
Jeg ser Binary, Unsigned, Usignert zerofill,
og på oppdatering aktuelle tidsstempel.
Dette feltet gjelder bare for noen numerisk felt
eller noen gang felt.
Så vi vil hoppe over som helt og holdent.
Null. Kan dette feltet være null?
Så nei. Vi har allerede den slags samtaler.
Så vi ønsker ikke en standardverdi.
Vi ønsker ikke at det skal være null.
Hva med indeksen?
Det er fire valg her.
Hva betyr det hvis vi spesifiserer
at denne raden kommer å være en primærnøkkel?
Tenker tilbake til CS50 eller CS165 hvis du har tatt det.
[Hørbar Remark]
Nettopp. Så en primærnøkkel ved definisjon er en felt
som identifiserer hver rad i denne tabellen.
Og du kan stole på det å gjøre som unik identifikasjon.
Så, hva betyr det deretter å bare være unik?
Vel, liksom disse to har liksom
på under implikasjoner under panseret.
Men generelt, er primærnøkkel slags kontrakt du gjør
med databasen ting.
Når jeg gjør spørringer på jakt etter et kurs,
Jeg kommer til å bruke denne bestemt felt.
Og vi vil komme tilbake til hvorfor vi kan ha to
slike valg her, eller unikt.
Unik bare sier, dette Feltet kommer til å være unikt
men jeg er ikke egentlig å gjøre noen slags verbal forpliktelse her
å bruke det feltet å gjøre mine søk
av grunner vi vil se på bare et øyeblikk.
Hvis vi angir i stedet indeksen, hva betyr det å spesifisere
at et felt har en indeks på det?
Yeah?
[Hørbar Remark]
Nettopp. Det har vært optimalisert for spørring.
Så du - databaseserver, Oracle, MySQL, uansett,
vil generelt gjøre sin magi bak kulissene når du klikker
at alternativet og klikk deretter Lagre og det vil bygge
opp vanligvis en trestruktur, B-trær hvis du har sett
eller hørt off, som er en svært kort utseende treet
som gir deg veldig fin logaritmiske eiendommer
når du søker på dataene.
Dersom du ikke angir en indeks på et felt, hva kommer
å være den løpende tid for å søke
for en vilkårlig [Fonetisk] kursnavn?
Hva er det?
[Hørbar Remark]
Oh, [uhørbart], lineære, ikke sant?
Hvis det er det ingen optimaliseringer gis til databasen
og du har ikke tenkt databasen hva slags
av data for å forvente.
Det beste du kan gjøre er å sjekke alt når du leter
for noen verdi, spesielt hvis det kunne
faktisk være duplikater.
Fulltekst i mellomtiden, skal vi wave våre hender for nå.
Men generelt, er dette en type indeks som gjør at du
å optimalisere for søkeord søker på et felt.
Så dette kan være en god kandidat
for som en kursbeskrivelse hvor du kan ha et par
avsnitt, og du kan ønsker å gjøre delstreng kampene.
Fulltekst vil vanligvis la du gjøre det ganske effektivt.
AI, er dette et fryktelig slag av forklaringen, men hvis vi sveve
enn det du vil se Auto Øk.
Ikke aktuelt både her men auto tilveksten er nyttig
for som en int felt fordi databasen vil ta vare
av prosessen med pluss plusing det hver gang du gjør en innsats.
Slik at selv om to personer bokstavelig klikk Send
på samme tid, og prøv å skape en rad liksom
i databasen, en av dem vil få nummeret jeg,
den andre vil få nummeret jeg pluss en.
Du trenger ikke å bekymre deg
om to tall som tildelt identisk hvis du var
å gjøre dette selv i kode.
OK.
Så jeg slags liker der vi har fått et navn å være.
Så la oss klikke Lagre.
Er dette en god design for en databasetabell?
Og som en side om rusten på SQL eller du liksom
av bare alltid slå en blind øye til hva som foregikk,
Jeg kunne ha skrevet akkurat det -
disse tre linjer om at svart og hvit teksten
i kommandolinjen klient eller jeg kunne ha gjort
at i kode programmatisk.
Så alt phpMyAdmin gjør for meg, er bare å spare meg innsatsen
å huske noen ganger syntaks og skrive ut for
som kjedelige kommandoer.
OK.
Så dette føles ikke som den beste design, en ett felt bord.
Nå kunne vi ha ting som professorer
og steder og beskrivelser.
Men selv da, kun ved hjelp av navn
å identifisere kurs føles ikke ideelt.
Hva har generelt vi gjort i fortiden
hvis du har brukt databaser Slik unikt rader?
Ikke bruker varchars typisk.
Yeah?
[Hørbar Remark]
Yeah. Så typisk et kurs ID.
Så, den vanligste nærme her spesielt
ved bruk av et rammeverk faktisk bare
å bruke et tall som et heltall.
Så la meg gå videre og gjøre dette.
Og vi kan gjøre dette i noen måter, men varsel hvis jeg zoomer
i på bunnen her.
Jeg kommer til å si legge en kolonner på slutten av tabellen,
generelt bare for visuell bekvemmelighet du putter IDer
ved begynnelsen av tabellen selv om dette ikke har noen reell
funksjonell betydning.
Så jeg kommer til å si legge til en kolonne
i begynnelsen av tabellen.
Jeg kommer til å klikke Go, som gir meg tilbake denne UI her.
La oss kalle denne ID.
Hvis vi tror vi er nødt til ikke mer gjort 4 millioner kurs
en int felt er greit.
Vi kunne selv krympe det ned
men plassen er billig så som virkelig bryr seg.
Men, vi prøver å skrive Facebook nå,
kan ikke være en dårlig ting å forutse store ints
som ville gi oss 64-bits ints
men så er du bokstavelig talt dobling av antall bits
at du bruker, så liten tradeoff
men noe å vurdere.
Nå er dette en forvirrende arven ting.
Dere husker kanskje at fra å bruke MySQL
at hver gang du erklærer en int feltet vil du ofte se en rekke
ved siden av det som nummer ti.
Det har ingenting å gjøre med størrelsen av antallet
eller antall bits.
Det har å gjøre med antall av tegn som benyttes
å visuelt visnings at int felt
ved bruk av en terminal.
Så vi kan se at i et øyeblikk.
Så ikke bli lurt ved å skrive tall
i det selv om det er effektivt å spørre oss
for en her.
Over her, kommer jeg til å gå foran og si usignert.
Det er ingen grunn til avfall alle våre negative tall
fordi databasen er generelt kommer
å anta positive verdier eller null.
Den ID definitivt bør ikke være null.
Og hva synes du om indeksen for denne ID-feltet?
La oss gjøre det primære.
Så, hva om, skjønt, som jeg kan bare tenke på en CS164 kurs
på Harvard og bare én CS50 kurs ved Harvard
og det er ganske mye sant generelle
at det er kanskje unntak [Uhørbart] begge semestre
eller noe merkelig sånn.
Men mer fundamentalt, hvorfor er det bedre
å bruke et numerisk integral ID til unikt identifisere kurs heller
enn bare en unik streng?
Yeah?
[Hørbar Remark]
OK, interessant.
Så hvis vi hadde liksom cross-listet kurs.
Så det er et godt eksempel.
Jeg er ikke sikker på at jeg ville løse det selv
ved å gi dem den samme ID-nummeret hvis det er
hvor du skulle med det.
Nei? OK. Men definitivt en hjørne sak å vurdere.
Hvis det er liksom - trenger vi noen slag
av aliasing potensielt.
[Hørbar Remark]
Jada.
[Hørbar Remark]
Det er et godt eksempel.
Navnet kan endres over tid, helt rimelig.
Hva annet?
[Hørbar Remark]
Beklager, si igjen.
[Hørbar Remark]
Ja, akkurat.
Så egentlig, det er den virkelige clincher er
at du bruker en 32-bit int er sannsynligvis kommer til å være raskere
enn noen variabel lengde røye feltet.
I det første tilfellet, kan bokstavelig talt passer i et register,
for ikke å snakke mye mindre minne fotavtrykk.
I sistnevnte tilfelle, du kommer å måtte gjøre resort [fonetisk]
til streng sammenligninger som i seg selv med den lineære
i størrelsen av string potensielt.
Så, det er bare en fin optimalisering,
og i særdeleshet det kommer
å la oss gjøre det som kalles Tiltrer mer effektivt
på bare et øyeblikk.
Så la oss gjøre det.
Vi vil presisere at Dette er primært
fordi jeg ikke spesielt ønsker å bry seg eller tenke
om hva nummeret er av et kurs.
La dem ta på hva verdier de ønsker.
Jeg kommer til å si auto tilveksten så jeg kan outsource som detalj.
Som i side du kanskje vet at Harvard
minst har unik tallene for kurs.
Jeg har ingen erindring hva denne kurs er.
Jeg vet at CS50 er Katalognummeret er 4949,
helt vilkårlig.
Men det er rart hjørne tilfeller i at selv
i registrarial dump selvfølgelig katalogdata,
noen ganger kurs, gamle kurs har et tall som fire.
Men teknisk sett at feltet er en char-feltet
som rett og slett begynner med 0004.
Så også her, må du være forsiktig med å skille
mellom ting som en kurskatalog nummer
som kanskje har noen menneskelige oppfatningen av fast lengde, 0004,
og du bør ikke lagres som for eksempel i en ints.
Den slags feltet bør være lagret et annet sted.
Så i Harvard, hvis vi var faktisk gjør et kurs
handle verktøy, er det sannsynligvis ikke tilstrekkelig
til antall kurs med bare 1, 2, 3, 4.
Vi kommer sannsynligvis til å ha
å ha et annet felt kalt katalognummer
som også er ment å være unik baserte
på menneskelige konvensjoner her men det er ikke det beste valget
for en unik identifikator fordi det kan være variabel lengde.
Det kan ikke være fire tegn, kan det være fem.
Faktisk tror jeg noen år siden de beveger seg
til fem tegn enes sak der var mer enn 999 kurs
totalt eller noe sånt det, eller 9999 kurs.
Så, som kan være et eksempel der feltet er ikke primære
men det bør være unike.
Og e-postadresse er en annen.
Du vil kanskje det å være unik
men ikke nødvendigvis din primærnøkkel.
OK.
Så la meg banke opp en annen Tabellen mye raskere enn dette.
Så jeg kommer til å kalle dette en Instruktører og jeg kommer
for å gi dette en total antall kolonner med to.
Jeg kommer til å lære min lekse fra forrige gang.
Jeg kommer til å ringe første kolonne ID.
Jeg kommer til å ringe Navn andre kolonne.
Jeg er også tenkt å gjøre Varchar.
Jeg kommer til å anta at det ikke professor har et navn lenger
enn 60 tegn, men nå dette kan være å skyve det
med noen lange navn, spesiell mennesker med mellomnavn.
Det er greit for i dag.
Så la oss rulle over her.
La oss gjøre dette usignerte igjen.
La oss gjøre dette primære.
Og vi vil gi like navn
i tilfelle det er to John Smiths eller noe sånt.
Og nå har vi to tabeller.
Så nå, trygler dette spørsmålet hvordan jeg forbinder
i instruktør med kurset?
Jeg føler at jeg slags fikk foran meg selv
fordi hvis en instruktør underviser,
mitt første instinkt ville faktisk være å gå tilbake
til kurs skjønner, dette var ikke en god idé.
La meg faktisk legge en kolonne ved enden av bordet,
klikk på Go, og jeg vil kaller dette Instruktør.
Og jeg vil gjøre denne varchar og jeg vil gjøre dette 60 år.
Og kanskje jeg skal la det null nå
Hvis emnet er ikke blitt Usignerte i instruktør
som noen ganger skjer før semesterstart og klikk på Lagre.
Hvilke av disse designene foretrekker du?
Først en der vi har en egen instruktør bord
eller den andre der vi bare legge til et felt til kurset?
Så det er en tett kobling instruktør med kurset.
[Hørbar Remark]
OK. Bra. Men la meg presse tilbake.
Det er bare så enkelt som jeg kan bare skriv inn navnet på personen
inn i denne tabellen, som sikkert som har noen verdi eller -?
[Hørbar Remark]
OK.
Vel, la meg være vanskelig her.
Så la meg si at dette kurset er CS51
og jeg vet det har lært i år av to personer.
Så, Henry Leitner og Jesse Tov men -
så jeg skal bare sette et komma mellom de to, rett.
Jeg er virkelig god til CSV fra en svunnen tid.
[Hørbar Remark]
Akkurat, akkurat.
Så snart du ty til noe sånt som dette,
som kan føle seg rimelig, og du kan føle
som dette er slags smart.
Jeg er liksom låne en idé som er å fungere godt,
låne en ny idé, og liksom kombinere dem.
Du slags helt beseiret det punkt av å bruke databasen
i første omgang fordi hvis en av verdiene
for å bruke det er raskere søk på grunn av de forskjellige indekser
og tabeller som kan bygges opp for deg
av databasemotoren selv.
Nå, hvis du ønsker å søke for alle kursene
at Jesse lærer, nå har du å gjøre delstreng matching på alle
av instruktør felt,
som effektivt betyr lineær søke på nytt fordi du har
å finne denne vilkårlig sett av tre tegn hvor som helst
i instruktør-feltet innledes
innenfor kanskje fulgt med komma.
Så dette definitivt lover ikke godt.
Så la meg gå tilbake til bordet.
La meg gå videre til kurs, angre det.
Jeg skal bare gå fremover og slippe det feltet.
Og hvis du ønsker å gjøre dette manuelt,
syntaksen er ALTER TABLE kurs DROP instruktør.
Så la oss gå videre og si ja til det.
Og gå tilbake til denne tidligere ideen
der jeg har en egen tabell for instruktører.
Men nå er dette føles litt som jeg kan sette et kurs
i løpet bord og instruktør
i instruktørens bordet, men jeg en eller annen måte trenger å koble de to.
Og hvordan ville du foreslår vi gjøre det?
[Hørbar Remark]
Bra. Så la oss gjøre det.
Og du kan kalle dette Tabellen i teorien noe.
Jeg kommer til å bevisst kall det hva mye
av rammer ville kaller det, blant dem,
Laravel som du vil se i litt.
Jeg kommer til å kalle det kurs underst instruktør.
Ved hjelp av entall i denne tilfelle for hvert av ordene
og små bokstaver igjen, og også med -
deretter alfabetisk sortert fra venstre til høyre.
Dette er helt vilkårlig, men det har en tendens til å være en konvensjon
i mange av disse rammene i PHP på andre språk.
Hvor mange kolonner trenger jeg dette er hva vi kaller en join tabellen,
å bli med to andre tabellene sammen?
Tre kolonner?
Hvilken - hva ville de være?
[Hørbar Remark]
OK. Bra. Som fungerer.
Og vi kunne teknisk kutte et hjørne her, men mye
av rammer i særlig ville likevel gi selv disse radene
unike ID-er selv om semantisk raden
at vi virkelig bryr oss om, eller kolonnene som vi virkelig bryr seg
om er de to sistnevnte hva du sa, kurset ID
og instruktøren ID.
Så la oss gjøre dette.
Jeg vil kalle denne raden bare ID, akkurat som vi gjorde før.
Men dette skal jeg å ringe kurs ID.
Dette kommer jeg til å ringe instruktør ID.
Og jeg kommer til å spesifisere at alle
av dem er usignerte Fordi jeg vil ha
å maksimere min 4 milliarder int range.
Ingen av dem skal være null.
Jeg kommer til å spesifisere at ID bør fortsatt være primær.
Og igjen, dette er bare en konvensjon,
en rekke rammeverk selv om du ikke sortere
av fundamentalt behov for en unik identifikator for raden,
det viser seg at det er praktisk for koden, SQL som kommer
å være automatisk generert for oss.
Så jeg skal la det som primær.
Men nå, jeg slags har et design beslutning,
Kurset ID og instruktør ID.
Hva indeksene hvis noen bør de få?
Hvis jeg skal la ingen indekser, hva er konsekvensen?
Hva er en implikasjon?
Ytelsen som før, ikke sant?
Hvis det ikke er noen indeks, jo beste du kan gjøre er snill
av [uhørbart] gjennom hele greia å se etter tall.
Så det føles ikke smart.
Skulle det være primær?
Så hvorfor ikke?
Hvorfor ikke primær?
[Hørbar Remark]
Perfekt. Så vi rulle ut [fonetisk] primære.
Vi valgte allerede det.
Så bør det være unik?
[Hørbar Remark]
Bra. Så, hvis du anta én instruktør per kurs,
helt greit.
Og det er definitivt felles sak
men vi allerede satt av en kanskje kjent eksempel.
CS51 fikk to instruktører så vi er snill
av nå skrudd i så fall.
Hvis vi tillot bare en instruktør,
vi kan faktisk gjøre en måte med skjøten tabellen helt,
gå tilbake til den tidligere tilnærmingen
og legger ikke personens navn kanskje, men instruktøren ID.
Hvis du kjenner hver kurs som bare en instruktør du kan ha rett
én kolonne.
Men variasjonen er hva fikk oss inn i trøbbel.
OK.
Så bør det være unik?
Nei Full tekst ikke føler aktuelt.
Som vi sa før det er
for som substring matching for beskrivelser.
Så hva med indeksen?
Vel, er indeksen trolig vår beste kandidaten
som forteller MySQL optimalisere for søk på dette
eller la meg utdype, optimalisere for søk eller sammenføyninger
som vi vil se i løpet av et øyeblikk
slik at de er en litt mer effektiv
enn noe rent lineær.
Ønsker jeg å auto intervaller dette feltet?
Så nei, fordi den sanne ordnet element finnes
i kursene bord.
Det er der det er kommer til å bli pluss,
pluss når det er faktisk innsatt.
Her er alt dette kommer manuelt inn
av oss antagelig i kode.
Så la oss bare spesifisere at både kurs ID
og instruktør ID har indekser.
Nå skal vi gå videre og redde.
Og nå, bare for å vise du korrespondanse
mellom hva som er en fin GUI grensesnitt
og kommandolinjegrensesnittet.
La meg gå videre og gjøre den følgende på denne MySQL teksten.
Jeg kommer til å si bruke courses50
som er den vilkårlige navn Jeg ga til denne databasen.
Og nå, gjør jeg ikke engang huske hva vi gjorde.
Så la meg typen show tabeller
og generelt semikolon vil være din venn her
å fullføre søket.
Og det er det.
Så her er radene eller snarere tabellene som vi har her.
Nå glemmer jeg hva et kurs ser ut,
så la meg ikke beskrive kurs og nå ser jeg liksom en ASCII
eller en versjon av hva phpMyAdmin gjorde
og jeg ser at ID er en int.
Det er at 10.
Hva betyr det?
Det betyr bare at når det er vises det kommer til å ta
opp 10 tegn på terminalvinduet.
Er det ha nullverdier?
Nei, dette er primærnøkkelen.
Kan det ha en standardverdi?
Nei Og ekstra som er spesiell flagg som automatisk tilveksten.
Så la oss bare gjøre et par kjappe innsettinger her.
Jeg kommer til å gå opp til - la oss bare si.
La oss endre tilstand til et lysbilde
hvor jeg liksom forhånds forberede dette.
Dette er en oppsummering deretter av alle tre av disse tabeller.
Jeg har allerede bare manuelt skrev den første kommandoen.
Og her, jeg gikk videre og skriver de andre for deg.
Dette er bare stilistiske ting.
Vanligvis mange mennesker skriver SQL-setninger i alle caps
og deretter tabellnavn og feltnavn i små bokstaver,
hvis bare fordi det slags stands
ut hva som er din terminologi og hva er databasen syntaks.
Så her har vi tre tabeller, kurs, instruktører,
og kurs instruktører.
I raset gjorde jeg på forhånd, Jeg hadde ikke ID-feltet
men det er faktisk ikke en dårlig ting i det hele tatt.
Vi ville bare se en tredje kolonne der.
Hadde jeg gjort det her?
Så nå la meg foreslå at vi gjør en haug med innsettinger.
Så her er noen data, Jeg vil zoome inn
Så jeg kommer til å foreslå at i kurs,
vi bare forholde seg til tre kurs.
Og jeg valgte disse tre Fordi de er representative
av noen fine - de har noen fine egenskaper.
CS1, CS50, CS51, de har økende IDer
men hva ID er hva er helt irrelevant.
Det er bare i hvilken rekkefølge de ble automatisk satt inn av meg.
Hva med instruktører?
Så nå, fordi Henry Leitner lærer både CS1 og CS51,
dette er litt av en anledning Implikasjonen for vår design.
Og Jesse lærer CS51 og Malan lærer CS50.
Så nå - eller rettere sagt disse er bare disse folks unike IDer.
Og kurs og instruktører, - kursinstruktører, legge merke til her.
Kurs ID1, som ble CS1 er undervist
av instruktør ID1 som er Henry.
Kurs ID2, som jeg tror ble CS50 er undervist
av instruktør ID2, som er Malan.
Og så til slutt, CS51, og legge merke til at vi har to rader.
Og nå er dette grunnen til at sammenføyningen Tabellen er kraftig undervises
ved både Henry og Jesse.
Så dette er alt fint og bra,
men jeg kan knapt husk på toppen
av hodet mitt hvem som er hvem her.
Hvordan kan du muligens håndtere det i kode,
uten å måtte harde kode ting?
Vel, dette er hvor SQL selv begynner å bli vår venn.
Og jeg kommer til å foreslå at vi kan skrive følgende.
Jeg skal gjøre dette på i Selve meldingen.
La meg gå videre og sette disse tingene.
Så, inn i kursene tabellen la oss gjøre akkurat hva vi hadde en
øyeblikk siden.
Jeg skal videre og si: la oss sette CS1 og CS50.
La oss sette inn noen flere rader på en gang, CS51.
Nå, la meg gå videre og redde.
Greit, så jeg er bare gjenskape så raskt
som jeg kan relasjonene vi nettopp så på skjermen.
Og så her har vi Leitner, her har vi Malan.
La oss gi oss selv en annen rad, og Tov.
Nå la meg lagre dette.
Og jeg gjør dem bevisst inn i den samme rekkefølge.
Nei, jeg glemte å gi denne bilen tilveksten.
La meg raskt fikse dette.
Jeg skal fikse dette i den elektroniske kode.
Som mislyktes som en side.
Det faktum at jeg ikke kunne Sett Leitner og Malan
og Tov mislyktes, fordi jeg gjorde ikke spesifisere et ID-nummer, selv om
det er ventet en og jeg glemte å sjekke auto tilveksten,
noe som betyr at de var alle som standard får null.
Men det så motsier som eiendom som vi har angitt.
Primærnøkkelen ble krenket så det gjorde ikke engang la meg gjøre det.
Så la meg fikse dette.
Nå, la meg gå tilbake til Sett kategorien her og angi
at jeg ønsker Leitner, Malan og, enda en rad, Tov.
Og nå til slutt, den eneste en som er litt vanskelig
å huske er selvfølgelig instruktør.
La oss sette inn nå som Kurset ID1 er instruktør ID1
så det er CS1 og Henry.
Kurs ID2 er instruktør ID2 som er CS50 og Malan.
Og så de siste som vi har å bekymre seg for er selvsagt ID3
som er CS51, blir undervist
av emnelærer 1, som er Henry.
Og tre som også underviste av tre, som er Tov.
Så forhåpentligvis nå Vi har gjenskapt dette -
faen, jeg gjorde det samme.
Kursinstruktør trenger auto tilvekst.
OK.
Jeg skal gjøre dette raskere denne gangen, selvfølgelig en, selvfølgelig en, to, to.
Og nå til slutt, gjør vi CS51 som har kurs ID3 og Henry.
Og selvfølgelig ID3 og Jesse.
Det ser bra ut.
OK. Så nå, la oss gå tilbake til terminalen vinduet.
Så hvis jeg beskrive kurs vi får se dette.
Hvis jeg ønsker å se kurs jeg kan nå gjøre velg stjerne fra kurs,
semikolon, og nå vi ser disse verdiene.
Og nå, hva annet ønsker jeg å gjøre?
Velg stjerne fra instruktører, det er som jeg forventet,
og velg stjerne fra kurs - Kurset strek instruktør.
Så hvordan gjør jeg nå delta disse tabellene?
Så skjønnheten av å ha valgt ID-verdier på denne måten er
at hvis du tenker på tar kurset tabellen
og instruktøren bord og deretter sette
i mellom de to i din sinn faglærer
tabell du kan slags tråd opp alle disse ID-kolonner
slik at du flette dem inn en massiv kolonne som har alt
av informasjonen vi bryr oss om.
SQL-syntaks for dette er ikke nødvendigvis åpenbar,
men la oss se om vi kan gjøre det.
Så velger stjernen fra kurs,
og det er noen måte som vi kan gjøre dette.
Jeg kommer til å trykke Enter bare for å slags format ting pent,
men at pilen er bare en symptom på klientsiden verktøyet
det har ingenting å gjøre med SQL seg selv.
Så velger stjernen fra kurs.
Jeg skal nå delta den kurs tabellen
på kurset instruktør tabellen.
Hvordan? På felt kalt courses.id tilsvar kurs
streker instruktør prikk hva er navnet
av det tilsvarende feltet her at jeg vil ha et par.
Det er ikke ID.
It '- hva, sorry?
>> Course ID.
OK, la meg zoome ut.
Men jeg ønsker å ta dette ett skritt videre.
Jeg har nå gjort dette bord og denne.
Nå ønsker jeg å trekke denne fyren i tillegg.
Så, la meg videre bli med dette hele greia
på instruktørens tabell på hva?
Kursstrek instructor.instructor id
tilsvar instructors.id.
Så vi kunne ha skrevet dette søket på flere måter.
I hvilken rekkefølge jeg gjorde dette er ikke så viktig.
Jeg bare slags gjorde det i mitt sinn fra venstre til høyre.
Vi kunne ha gjort dette i de få forskjellige måter
men hvis jeg har nå semi kolon og trykk Enter,
merker jeg får tilbake en ny midlertidig tabell, et resultatsett
så å si i databasen tale.
Og hva har jeg i denne saken?
Jeg har på ID, et navn, en annen ID, som er slags forvirrende
til meg i øyeblikket, et kurs-ID,
en instruktør ID, ID, og ​​navn.
Så, ved slutten av dagen vi har de riktige data nå.
Jeg kan se at CS1 blir undervist by Leitner, er CS51 undervist
by Leitner og Tov, og CS50 er undervist av Malan.
Men jeg er litt nervøs denne tvetydigheten jeg har laget.
Hva er tvetydighet Jeg henviser til?
Yeah?
[Hørbar Remark]
Det er tre ID-kolonner.
Så vi kan faktisk fikse dette og vi skal faktisk kommer
å utsette til vårt rammeverk slutt å hjelpe oss med dette,
men det viser seg at det er et nøkkelord i SQL kalt S,
der du kan angi en alias, et nytt navn på et felt
slik at vi kan unngå dette tvetydighet helt.
Men innså at hvis vi ikke gjør det ta det opp en eller annen måte som med
dette søkeordet eller et rammeverk,
det er potensielt dette tvetydighet hvis du prøver
å få tilgang til ID-feltet fordi klart det er de
med like navn der.
Så dette er et delta og jeg tror i ditt indre øye den beste måten
å tenke på det egentlig er å ta de to bord,
line dem opp i slik du vil.
Og dette er en såkalt indre delta i den forstand
at vi kombinerer tabellene her.
Det finnes andre typer tiltrer som vi kan støte
over tid som ytre sammenføyninger,
men for det meste dette er trolig den vanligste
for å rekonstruere data.
Det vi har gjort nå er vanligvis det som kalles
normalisering dine data, slik at det er ingen duplisering hvor som helst
i tabellene.
Og ved duplisering, ville jeg har ført til at første tilnærming.
Hvis vi hadde nevnt Leitner og Tov på flere steder
i databasen din, det er ikke vanligvis den beste beslutningen
spesielt hvis deres navn makt endre overtid eller i tilfelle
av ekteskap, pikenavn makt endre seg du bare ønsker en
kanoniske sted for noen dataverdi som et navn.
OK.
Så, for å oppsummere, har vi hatt en noen design beslutninger å gjøre
og de mest viktige trolig redusert til noen
av disse valgene av indekser.
Men la meg påpeke en annen ting også.
Hvis jeg går tilbake til phpMyAdmin,
en funksjon du kanskje ikke har møtt før er
følgende.
Hvis jeg går til kursinstruktør, Jeg allerede har angitt at noen
disse tingene har indekser.
Men la meg gå til strukturen kategorien av faglærer.
La meg Klikk nå på avskriftene og legge merke til følgende.
Jeg har spesifisert her at det er en primærnøkkel
på en kolonne kalt ID.
Dette er en noe komplisert måte å angi kardinalitet
og så videre som en henvisning til størrelsen av feltet i byte.
Men nå har jeg også en annen feltet, kurs-ID, som er -
Kurset ID som er gjort på forhånd og unik, OK.
Jeg gjorde dette i avansere for oss.
Så, hvorfor er dette - la meg slippe Dette av hensyn til diskusjonen.
Åh, vet du hva jeg gjorde?
OK. Så tidligere, en av de farene ved å bruke et GUI verktøy
som dette, da vi var Opprette dette bli bordet,
faglærer tabellen, husker at jeg spesifiserte
at jeg vil ha en indeks på dette feltet
og en indeks på dette andre felt.
Denne bivirkning av sjekke begge disse boksene
på samme skjerm er at phpMyAdmin utledes fra det,
at jeg ønsker ikke to separate indekser,
at jeg vil ha en delta indeks som er generelt bare nyttig
eller mest nyttig når du er søker på ikke ett felt
men begge disse felter.
Og det er derfor vi hadde dem conjoin det
så jeg droppet det fordi at var ikke det jeg hadde tenkt.
Snarere, jeg kommer å gjøre om dette her.
Jeg kommer til å gå til kurset ID
og under mer jeg er bare kommer til å si legge indeksen.
Og jeg kommer til å gå under instruktør ID og si legge indeksen.
Og nå hvis vi klikker her, merker vi har tre indekser,
en primær og som jeg beregnet på en for hvert
av disse fremmednøkler.
Og jeg kaller det fremmed grunn Kurset ID i denne tabellen maps
til hvilket felt, bare for å være tømme, i en annen tabell.
Primærnøkkelen kalt ID, i tabellen som heter kurs,
og samme avtale for den andre.
Men nå, er en interessant lure og virkelig teknikk.
Jeg bare gikk videre og la meg gjøre det litt langsommere.
I den samme skjermen, varsel det står Relation visning her.
Jeg klikker på denne og nå merker jeg komme til å gjøre et par begrensninger.
Så, en av de oppsider også
av ikke bare å bruke konseptuelt fremmednøkler og andre tabeller
som vi har bare på er at ved å definere en indeks
på dem kan du ha database hjelpe deg enda mer
sikre integriteten av dette feltet.
Nærmere bestemt, kan jeg nå spesifisere via denne rulle
ned at kurset ID-feltet
i denne tabellen faktisk Kartene på å courses.id.
Tilsvarende, instruktør strek ID tilordnet instructors.id.
Nå, hvorfor er dette nyttig?
Vel, legge merke til, på høyre side hva som vises nå.
Jeg kan nå lære database som om Henry
for eksempel noen gang trekker seg og rad hans forsvinner
fra instruktøren bord helt dermed være
slettet, kan jeg via dette gripende tilnærming sikre
at eventuelle kurs han lærer er ikke lenger forbundet med ham.
Jeg kan lære databasen å slette radene
Denne såkalte delta tabell automatisk hvis Henry eller hvis en
av hans kurs forsvinner.
Nå, hvorfor er dette overbevisende?
Yeah?
[Hørbar Remark]
Du trenger bare å gjøre det en gang og lengre sikt, ikke sant?
Det er veldig enkelt hvis slags folk kommer og går, kurs kommer
og gå, databasen kunne bare bli strødd med kurs
og med fakultetet som er no lenger relevant for datasettet.
Og dataene dine begynner å bli veldig rotete og skittent og bedervet,
og så her kan vi sortere
av håndheve noen av disse begrensningene.
Yeah?
[Hørbar Remark]
Den vet ved hjelp av dette.
Dette er skjermen der vi spesifiserer en kobling
mellom fremmednøkkel og primærnøkkel.
Så alt av navngiving konvensjoner jeg antydet
til tidligere er bare konvensjoner.
Det er ingen iboende mening.
Dette er skjermen som er bare nyttig
etter at du spesifiserte indekser på hver av disse feltene som vi gjorde.
Og for denne dropdown vi har et par ting for eksempel
Hvis et kurs er slettet kan du faktisk hindre at sletting
skjer hvis det er en rad i denne tabellen
ved å bare si, Begrense.
Med andre ord Henry kan ikke pensjonere
før vi isolerer ham fra CS51 og CS1.
Så det er en god ting.
Men det kunne utløse feil i koden
hvis du ikke forventer det, eller vi kan ha en kaskade,
en kaskade ligner liker Cascading Style Sheets
og gjennomgripende foss betyr at dersom en -
hvis Henry trekker seg så - ved å bli slettet
så vil hans rad her bli slettet.
Ingen handling betyr ingenting eller null er slags nyttig hvis du snill
av ønsker litt historisk rekord av Henry har undervist CS51,
men du bare ønsker at feltet for å være null, slik at radene der
men det er ikke lenger assosiert med ham.
Så dette er veldig kraftig teknikker som du kan
og bør bruke selv om i renter spesielt
å redde deg fra deg selv.
Så la meg gjøre omtale av en par endelige detaljene her,
bestanddeler med hvilken som kan være nyttig
som vi planlegger for databasedesign.
Du har også valget over databasemotor
som du bruker i koden din.
Hvis du er kjent av CS161 du kanskje -
eller til og med 61, kanskje du vanligvis være kjent med filsystemer.
Og det er ting som, NTFS og HFS +
og X2FS4 [fonetisk] og 3, og så videre.
Det er forskjellige måter til å lagre data på pulten.
Tilsvarende er det forskjellige måter å lagre dataene
i en database som standard i hvert fall i Appliance
med den nyeste versjonen av MySQL.
Vi har brukt databasemotor kalt, NoDB,
som støtter en noen fine funksjoner.
Men en annen vanlige er også kalt MyISAM og enda en
som kan brukes er minne, noe som betyr at du ikke sette noe
på disken, bare holde ting i minnet.
For det meste har du sannsynligvis vil ikke gå galt bare å starte
med NoDB, men for noen prosjekter som har en tendens til å involvere høye priser
for innsetting f.eks som en masse rask logging,
hundrevis av ting per sekund eller tusenvis av ting.
Når som helst du har en masse ting som skjer
on i databasen så denne typer
av lavere nivå beslutninger begynner å bli involvert.
Den fullstendige teksten funksjonen for eksempel fungerer bare i MyISAM
slik som har en innblanding.
Men du husker kanskje dette, la oss minst motivere hvorfor vi bryr oss
om NoDB spesielt.
Et race conditions vanligvis refererer til hva?
Greit, dette er en hentydning til et eksempel noen
av dere kanskje har hørt i år tidligere enten 161 eller 50
hvor du har en samboer, dere begge virkelig liker melk,
en av dere kommer hjem først åpner kjøleskapet er det ingen melk,
lukke kjøleskapet spasertur over gater til CVS og få
i kø for å kjøpe melk.
I mellomtiden, romkameraten kommer tilbake hit.
Hun liker også melk.
Åpner kjøleskapet og innser ingen melk.
Her så går hun til lagre, kanskje den andre CVS.
Spol frem et par minutter senere du kommer tilbake, og nå både
av dere har kjøpt melk.
En av dem går nå å ødelegge fordi du ikke
som melk så mye og dette er et problem, ikke sant?
Fordi dere begge inspisert staten noen variabel
og tatt en avgjørelse basert på den, selv om tilstanden
av den variabelen var i hovedsak i ferd med å bli endret,
alle være det sakte over hvor lang tid det tar
å komme til og fra CVS.
Så hva er en slags dum real verden løsning på det problemet?
Legg igjen en kommentar, ikke sant?
Det skjedde sist gang.
Alltid forlate et notat eller hengelås ting bokstavelig.
Og jeg sier hengelås, fordi hvis du tar eller tok CS161,
låsing er en fundamental Ideen i den slags verden.
Så race conditions kan oppstå også i databasen verden
og du kanskje husker kanskje fra CS50 finansiere hvis du tok 50,
denne koden at vi faktisk ga dere i spesifikasjonen
på den tiden, slik at din Operasjonen er såkalte atom.
Hvis du ville, i dette tilfelle, kjøpe en andel på lager
og at aksjen har noen bestemt symbol.
Vi fortalte deg å bruke kode som denne, for ved hjelp av denne
på duplikatnøkkel oppdatering syntaks, som er bygget
inn i MySQL du er effektivt gjør enten i innsats
eller i oppdatering etter gjør en utvalgt til å se
hvis en aksje er allerede der.
Med andre ord, den analoge i verden for å kjøpe en aksje
av melk og kjøleskapet kan være, først,
før du kjøper en andel av Google vil du kanskje velge
fra databasen alle aksjer i Google som David eier
for å se om han eier null eller mer.
Når du se om han eier null eller mer du har
å så gjør følgende.
Du enten nødt til å gjøre en innsats
hvis han eier null fordi det er ingen rad for David ennå,
eller du trenger å gjøre en oppdatering hvis i det minste i teorien du vil
å ha en rad per bruker.
Problemet er å velge at antall aksjer
og deretter oppdatere eller innsetting kan bli forstyrret
av noen andre på en annen dataterminal prøver å kjøpe
eller selge noen av Davids aksjer aksjer hvor
for gode formål eller sortere av skadelige formål.
Det er som å gå til butikken når romkameraten kommer tilbake
og kontrollerer staten av den variable.
Så denne syntaksen på den tiden som var liksom riktig
for CS50, unngår at problemet helt.
Og det bare gjør alt som magi av låsing for deg,
men nå med slike prosjekter for dette kurset
som mest sannsynlig vil involvere mer komplekse datasett,
du kan ikke oppnå alltid dette atomicity.
Alt skjer på en gang, eller ikke i det hele tatt
uten avbrudd så elegant.
Og så MySQL, en annen databasemotor,
støtte ting kalt låser,
der du kan si lås dette bordet slik at bare en godbit
og generelt bare én bruker kan berøre det på noen tidspunkt
å lese eller skrive og så kan du låse den opp.
Dette er et eksempel fra én av MySQL egne referanser,
der hvis du har som en bank konto som du prøver
å trekke penger fra og deretter legge penger til.
Du ønsker kanskje å sørge for at både
av disse tingene skje sammen
slik at det er ingen matematiske feil
Og ingen tap penger, liksom.
Problemet med låser men i en database er
at det betyr generelt hele tabellen er låst,
som betyr at hvis du har hundre mennesker prøver
å gjøre forretninger med banken din online på samme beløp
tid bare én av dem kan gå av gangen.
Som er dumt, spesielt på servere i dag
som har åtte kurs, 16 Selvfølgelig har en enorm mengde
minne, er det ingen grunn til å serialiseres alle
av dine transaksjoner hvis de kundene bare skal
å samhandle med sine egne rekker.
Så NoDB lar deg gjøre ting mer intelligent
, og dette vil generelt bli tilnærmingen du ta i kode,
som du bruker noe kalt transaksjonen.
Og du gjør dette generelt i PHP-kode,
Ruby-kode, Python, uansett.
Men SQL-kode som er til slutt brukes er dette,
typisk.
Begynn transaksjon så du spesifisere to eller flere spørringer
at du ønsker å kjøre helt
uten avbrudd eller ikke i det hele tatt.
Det kan også være noen velg uttalelser i
eller noen sletter eller oppdateringer.
Men det fine er at den databasen vil være smart nok
å sørge for at det vil bare låse rader de er faktisk
involvert i denne oppdateringer eller merke eller sletter.
Så hvis du fikk tusenvis av rader og du er bare berøre tre
av dem, bare at delsett av tabellen vil bli låst
noe som betyr at de andre 99 kunder kan berøre sine rekker
uten å bli serialisert og bremset ned av deg.
Samtidig er dette den fineste aspekt til transaksjoner.
De er transaksjoner i en oppfatte som 161 på et filsystem,
de er transaksjons
som betyr at du kan rulle dem tilbake, kan du angre dem.
Dette er som kommandoen eller kontrollere F av databaser.
Hvis du oppdager en del gjennom alle
av ulike datadrift, skyte, er noe som går galt.
Du bokstavelig talt utføre en forskjellige SQL-spørring rulle tilbake
og alle disse trend - alt av uttalelsene du henrettet
etter å si start transaksjonen forsvinne
som om de aldri har skjedd,
som er en utrolig mektig ting.
Og dette er de typer ting sikkert i 50 vi sorterer
av feie under teppet og du bare slags anta
at alt vil bli bra.
Men når du begynner tenker på reelle prosjekter
og reelle brukere og integriteten til databasen,
disse er de typer av design beslutninger
som kommer til å være viktig.