[TÓNLIST spila] DOUG LLOYD: In vídeó okkar á vefur þróun málefni, við höfum getið hugtakið gagnagrunnur nokkrum sinnum, ekki satt? Svo gagnagrunn þú ert líklega kannast við frá segja að nota Microsoft Excel eða Google töflureikni. Það er í raun bara skipulögð setja af borðum, raðir og dálka. Og gagnagrunnur þar website verslanir okkar upplýsingar sem er mikilvægt fyrir okkar website til að vinna almennilega. Aftur, mjög algengt dæmi hér er að geyma notendanöfn og lykilorð í gagnagrunni, þannig að þegar sem notandi skráir sig inn á heimasíðu okkar, gagnagrunninum má fletta til að sjá ef notandinn er í dag. Og ef þeir eru, athuga hvort Aðgangsorðið er rétt. Og ef lykilorð þeirra er rétt, þá getum við gefið þeim hvað síðu þeir eru að biðja. Svo þú ert líklega aftur, ég þekki með þessa hugmynd frá Excel eða Google Tafla. Við höfum gagnagrunna, töflur, línur og dálka. Og það er í raun eins konar af grundvallar sett hierarchic sundurliðun hér. Svo hér er Excel töflureikni. Og ef þú hefur einhvern tíma opnað þetta eða annað slíkt forrit þú veist að þetta eru hér rows-- 1, 2, 3, 4, 5, 6, 7. Þetta eru dálkar. Kannski niður hér, þótt þú getur ekki nota þennan eiginleika hræðilega much-- Ég stækka in-- við höfum þessi hugmynd um blaði. Svo vill þessi blöð, ef Ég varamaður og til baka, eru mismunandi töflur sem eru hjá mér. Og ef við höldum áfram Example allt vegurinn, nafn af þessum gagnagrunni er Book 1. Kannski hef ég Book 2 og 3. bók. Svo er hver Excel skrá a gagnagrunnur, hver lak er borð, og inni hverri töflu sem ég hef þessi hugmynd af línum og dálkum. Svo hvernig get ég unnið með þessum gagnagrunni? Hvernig fæ ég upplýsingar frá henni? Jæja það er tungumál kallast SQL-- sem ég yfirleitt bara kalla Sequel-- og það stendur fyrir Structured Query Language. Og það er forritunarmál, en það er nokkuð takmörkuð forritun tungumál. Það er ekki alveg eins og aðrir sem við höfum unnið með. En tilgangur þessarar forritunarmál er að fyrirspurn í gagnagrunn, til spyrja upplýsingar gagnagrunns, finna upplýsingar á a gagnagrunnur, og svo framvegis. Við höfum einnig í CS50-- og það er mjög sameiginlegur vettvangur, það er kallað MySQL. Það er það sem við notum á námskeiðinu. Það er opinn hugbúnaður vettvangur sem stofnar svonefndan Vensla database-- gagnagrunni, á áhrifaríkan hátt. Við þurfum ekki að fá í of mikið smáatriði á hvaða Venslagagnagrunnur er. En SQL tungumál er mjög Adept á að vinna með MySQL og annað svipað stíll Vensla gagnagrunna. Og margir innsetningar MySQL koma með eitthvað heitir phpMyAdmin, sem er myndrænt notandi interface-- á GUI-- sem gerir það svolítið meira notendavænt að framkvæma gagnasafn fyrirspurnir, vegna gagnagrunnar eru ekki bara notuð af háþróaður forritari, ekki satt? Stundum eru þessir litlu fyrirtæki, og þeir geta ekki efni á að ráða teymi af forriturum, en þeir þurfa samt að geyma upplýsingar í gagnagrunninum. Eitthvað eins og phpMyAdmin gerir það mjög auðvelt fyrir einhvern sem hefur aldrei forritað áður að taka upp og kynnast því hvernig að vinna með gagnagrunni. Vandamálið er, phpMyAdmin, en það er frábært tól til að læra um gagnagrunna, það er handbók. Þú ert að fara að þurfa að skrá þig inn það og framkvæma skipanir og tegund hlutir í höndunum. Og eins og við þekkjum úr okkar dæmi um PHP forritun vefur, þurfa að höndunum gera það á heimasíðu okkar, ef við viljum a dynamic, virk móttækilegur website, kannski ekki besta nálgun. Okkur langar til að finna leið til að kannski sjálfvirkan þetta einhvern veginn. Og SQL mun gera okkur kleift að gera þetta. Svo þegar við erum að fara að byrja að vinna með SQL, Við þurfum fyrst að hafa gagnasafn til að vinna með. Búa til gagnagrunn er eitthvað sem þú sennilega gert í phpMyAdmin, því þú þarft aðeins að gera það einu sinni, og setningafræði fyrir að gera svo er mikið meira einfalt. Það er mun auðveldara að gera það í grafískri notendaviðmót en að slá það út sem skipun. Skipunin getur fengið smá fyrirferðarmikill. Á sama hátt, búa til töflu getur fá töluvert fyrirferðarmikill eins og heilbrigður. Og svo hlutir eins og að búa til gagnagrunn og skapa borð, sem þú ert sennilega bara að fara að gera once-- einu sinni á borð, einu sinni á database-- það er í lagi að gera það í myndrænt viðmót. Í því ferli að búa til borð, þú munt einnig að tilgreina allt í dálka sem verður í þeirri töflu. Hvers konar upplýsingar gera þú vilt geyma í töflunni? Kannski nafn notanda og fæðingardag, lykilorð, notandi ID númer og kannski borg og ríki, ekki satt? Og í hvert sinn sem við viljum bæta notanda að gagnagrunninum, við viljum fá öll sex af þeim stykki af upplýsingar. Og við gerum það með því að bæta raðir á borðið. Svo við að búa fyrst til gagnagrunn, þá erum við að búa til töflu. Sem hluti af að búa borð, við erum beðin að tilgreina hvert dálk sem við viljum í þessari töflu. Og þá eins og við byrjum að bæta upplýsingar í gagnagrunn og fyrirspurn í gagnagrunninn meira generally-- ekki bara bæta við, en allt annað sem við do-- við munum vera að fást með raðir af borðinu, sem er eitt upplýsingar um notanda frá allt sett. Svo er hver SQL dálki fær um halda gögnum um tiltekna tegund gagna. Þannig að við útrýma svoleiðis þetta Hugmyndin um gagnatög í PHP, en þeir eru aftur hér í SQL. Og það er mikið af gagnatög. Hér er bara 20 af þeim, en það er ekki einu sinni þeim öllum. Þannig að við höfum hugmyndir eins INTs-- Integers-- við vitum líklega að þessi dálkur getur haldið heiltölur. Og það eru afbrigði thereon-- SMALLINT, TINYINT, MEDIUMINT, BIGINT. Kannski eigum við ekki alltaf þörf fjögur bit. Kannski þurfum við átta bæti, og svo við getur notað þessi afbrigði á heiltölur að vera svolítið meira pláss duglegur. Við getum gert aukastaf númer, við getur gert fleytitölu númer. Þetta eru mjög svipuð. Það eru nokkrar mismunandi, og ef þú vilt eins og að horfa upp SQL konar handbók, þú hægt að sjá hvað lítilsháttar munur er á milli þeirra. Kannski viljum við geyma upplýsingar um dagsetningu og tíma. Kannski erum við að halda utan um þegar notandi gekk heimasíðu okkar, og svo kannski við viljum að hafa dálk sem er dagsetning tími eða timestamp sem gefur til kynna þegar notandinn í raun skráði sig. Við getum gert geometries og linestrings. Þetta er reyndar mjög flott. Við gætum kortleggja a landsvæði með GIS hnit að samsæri út svæði. Svo getur raunverulega geyma þessi tegund upplýsinga í SQL dálki. Textinn er bara risastór dropar af texta, kannski. ENUMs eru eins konar áhugavert. Þeir eru í raun í C. Við gerum ekki tala um þá vegna þess að þeir eru ekki hræðilega algengt, að minnsta kosti CS50. En það er ertölusettur gögn tegund, sem er fær um að halda takmörkuð gildi. Virkilega gott dæmi hér væri til að búa til enum þar sem sjö Möguleg gildi eru sunnudagur, mánudagur, Þriðjudagur, Miðvikudagur, Fimmtudagur, Föstudagur, Laugardagur, ekki satt? Þessi gögn tegund Dagur Viku er ekki til, en við gætum búið til að talin gögn tegund, svo að það dálki getur bara alltaf haldið einn af þeim sjö gildunum. Við höfum talin öll af gildunum. Þá höfum við CHAR og VARCHAR, og ég hef lita þessar grænu vegna þess að við erum í raun og veru fara að taka annað að tala um muninn á milli þessara tveggja hluta. Svo CHAR, ólíkt C þar CHAR var einn staf, í SQL a CHAR átt við fast band lengd. Og þegar við að búa til þessa dálki, reyndar við Hægt er að tilgreina lengd strengsins. Þannig að í þessu dæmi, við gætum sagt bleikju (10). Það þýðir að hver þáttur þeim dálki mun samanstanda af 10 bæti af upplýsingum. Ekkert meira, ekkert minna. Þannig að ef við reynum og setja í 15 bita eða 15 stafir þáttur eða gildi í þessum dálki, við erum bara á fyrstu 10. Ef við setjum í tveimur eðli lengi gildi, við erum að fara að hafa tvær stafi, og þá átta null bit. Við munum aldrei vera skilvirkari en það. A VARCHAR er góður af eins og hugmynd okkar um streng sem við erum kunnugir með úr C eða PHP. Það er breyta lengd strengur. Og þegar þú býrð þessi dálkur, þú bara tilgreina hæsta mögulega lengd. Svo kannski 99 eða almennt 255. Það væri hámarkslengd. Og svo ef við vorum að geyma 15 stafir band, við myndum nota 15 bæti, kannski 16 bæti fyrir null Terminator. Ef við vorum að geyma a þrír eðli band, við myndum nota þrjú eða fjögur bæti. En við myndum ekki nota fullt 99. Svo hvers vegna ættum við að hafa bæði? Jæja, ef við þurfum að reikna út hvernig lengi eitthvað er með VARCHAR, við höfum að eins konar árétta yfir það eins og bara að við gerðum í C og reikna út hvar það hættir. En ef við vitum að allt í þessum dálki er 10 bytes, kannski við vitum að upplýsingar, við getum hoppað 10 bæti 10 bæti 10 bæti 10 bæti, og alltaf finna byrjun af the band. Þannig að við kann að hafa nokkrar sóun pláss með bleikju, en kannski er það verslun burt af hafa betri hraða í siglingar í gagnagrunninn. En kannski viljum við sveigjanleika á VARCHAR í stað þess að having-- Ef CHAR okkar var 255, en mest af notendum okkar voru aðeins inputting þrjú eða fjögur bæti virði á upplýsingum eða þremur eða fjórum stafir virði af upplýsingum. En sumir notendur voru að nota allt 255, kannski VARCHAR væri meira viðeigandi þar. Það er tegund af viðskiptum burt, og almennt í þeim tilgangi að CS50, þú þarft ekki að hafa áhyggjur of mikill óður hvort sem þú notar bleikju eða varchar. En í hinum raunverulega heimi, þetta ekki máli vegna þess að allir af þessum dálkum taka upp raunverulegt líkamlegt pláss. Og líkamlegt pláss, í raunverulegur veröld, kemur á reikningi. Svo eitt annað endurgjald þegar þú ert að byggja upp töflu er að velja einn dálk til að vera hvað er kallað aðal lykill. Og aðal lykill er dálkur þar sem hvert einasta gildi er einstakt. Og það þýðir að þú getur auðveldlega velja út eina röð með því að horfa á aðal lykill röðinni. Svo til dæmis, þú almennt, við notendur, vil ekki tveimur notendum sem hafa sama notanda kennitölu. Og svo kannski þú hafa hellingur af upplýsingum, og kannski tveir notendur geta hafa sömu name-- þú þarft John Smith og John Smith. Það er ekki endilega vandamál, vegna þess að það eru margar fólk í heiminum sem heitir John Smith. En við höfum aðeins einn notandi kennitölu 10, einn notandi ID númer 11, 12, 13. Við höfum ekki tveimur notendum með sama fjölda, og svo kannski tölur notandanafn væri gott aðal lykill. Við höfum ekki neina tvíverknað, og við getum nú einstaklega þekkja hvert einasta róður bara með því að horfa á þeim dálki. Velja aðallykla getur raunverulega gera síðari borð rekstur mun auðveldara vegna þess að þú getur skiptimynt Sú staðreynd að tiltekin raðir muni vera einstakt, eða ákveðin dálk af gagnagrunni eða borð mun vera einstakt að velja ákveðinna raðir. Þú getur einnig hafa sameiginlega aðal lykill, sem þú getur fundið tilefni að nota, sem er bara blanda af tveimur dálkum sem er tryggt að vera einstakt. Svo kannski þú hafa einn dálk sem er Sem og Bs, einn dálk sem er einn, tveir, og þrír, en þú munt bara alltaf hafa einn A1, skal eitt A2, og svo framvegis og svo framvegis. En þú might hafa a B2, a C2, eða A1, A2, A3, A4. Svo þú gætir þurft margar As, margar Bs, margar sjálfur, margar twos, en þú getur bara alltaf hafa Single A1, B2, C3, og svo framvegis. Svo eins og ég sagði, SQL er forritunarmál, en það hefur nokkuð takmarkað orðaforða. Það er ekki alveg eins þenjanlegur og C og PHP og öðrum tungumálum að við tölum í námskeiðinu. Það er meira fjölorður a tungumál en það sem við erum að fara að tala um í þessu video, vegna þess að í þessu myndbandi við erum að fara að tala um fjórum aðgerðum sem vér getur framkvæmt á borði. Það eru fleiri en þetta. Við getum gert meira en þetta, en með tilliti til okkar, við erum almennt að fara að vera með bara fjórar operations-- settu, velja, uppfæra og eyða. Og þú geta sennilega innsæi giska hvað allir fjórir af þessum hlutum að gera. En við munum fara í smá nákvæmni á hverjum og einum. Svo í þeim tilgangi að þetta video, við skulum gera ráð fyrir Við höfum eftirfarandi tveimur töflur í einum gagnagrunni. Við höfum töflu sem kallast Notendur sem hefur fjögur columns-- kennitala, notandanafn, lykilorð, og fullt nafn. Og við höfum annað borð í sama gagnagrunni kallað mömmum sem bara geymir upplýsingar um notandanafn og móður. Svo fyrir alla dæmum í þessu myndbandi, munum við að nota þennan gagnagrunn og síðari uppfærslur á henni. Svo skulum segja að við viljum að bæta upplýsingum við borðið. Það er það sem innskotið rekstur gerir. Í að útskýra allt Þessar skipanir, sem ég ætla að gefa þér almenna beinagrind til að nota. Því í grundvallaratriðum, fyrirspurnir eru að fara að líta nokkuð svipað, við erum bara að fara að vera að breytast örlítið mismunandi stykki af upplýsingar að gera mismunandi hluti við borðið. Svo fyrir INSERT, beinagrind lítur svona eins og þetta. Við viljum að setja inn sérstaklega borð. Þá höfum við opið sviga og lista yfir dálka að við viljum setja gildin inn. Loka sviga er Eftirfarandi gildi, og þá aftur, listi við út gildi við viljum að setja í töflunni. Svo dæmi um þetta myndi vera eftirfarandi. Ég vil setja inn töflu notendur eftirfarandi columns-- notandanafn, lykilorð og fullname. Svo nýja röð þar sem ég er að setja í þeim þremur dálkum og við erum að fara að setja í gildi Newman, USMAIL og Newman. Þannig að í þessu tilfelli, ég er setja lágstafir Newman í notendanafni dálki, lykilorð USMAIL, og fullt nafn höfuðborg N Newman í fullname dálki. Svo er hér það sem gagnagrunnurinn leit út eins og áður. Hér er það sem notendur borð á toppur leit út áður en við gerðum þetta. Eftir að við framkvæma þetta fyrirspurn, fáum við þetta. Við höfum bætt við nýrri línu í töflunni. En taka þetta eitt sem ég gerði ekki tilgreina, en einhvern veginn ég hef fengið gildi fyrir, sem er þessi 12 hérna. Ég sagði ekki að ég vildi setja kennitölu í það. Mig langaði til að setja notendanafn, lykilorð, fullname. Og ég gerði það, það er allt í lagi. En ég fékk líka þessa 12. Af hverju gerði ég það 12? Jæja, það kemur í ljós að þegar þú ert að skilgreina dálk sem er að fara að vera þinn aðal lykill, sem er yfirleitt, eins og ég sagði, kennitölu. Það er ekki alltaf endilega að fara að vera kennitala, en það er yfirleitt góð hugmynd að vera einhvers konar heiltölu gildi. Þú hefur möguleika á phpMyAdmin þegar þú ert að búa gagnagrunninn eða borð til að setja sem dálki sem farartæki incrementing. Sem er mjög góð hugmynd þegar þú ert að vinna með aðal lykill, vegna þess að þú vilt hvert gildi í þeim dálki til að vera einstakt. Og ef þú gleymir að tilgreina það meira en einn mann, þú hefur nú ástandið þar sem dálkur er ekki lengur einstakt. Þú hefur tvo eyðurnar, svo þú getur ekki lengur einstaklega þekkja column-- eða þú getur ekki lengur einstaklega þekkja röð byggt á þeim dálki. Það er glatað öllum sínum gildi sem aðal lykill. Og svo virðist sem ég hef gert hér er stillt kenni Súlan farartæki vöxtur þannig að hver þegar ég bæta upplýsingum við borðið, það vilja á sjálfvirkan hátt gefa mér gildi fyrir aðal lykill. Þannig að ég get aldrei gleyma að gera það vegna þess að gagnagrunnur mun gera það fyrir mig. Svo er það góður af gaman. Og svo er það þess vegna sem við fáum 12 í það, vegna þess að ég hef setja þessi dálk upp til sjálfvirkt farartæki vöxtur. Ef ég bætti einhver annar það væri 13, ef ég bætti einhver annar að það væri 14, og svo framvegis. Svo skulum gera bara eitt innsetningu. Við munum setja inn moms borð, í Einkum notandanafn og móðir súla, gildi kramer og Babs Kramer. Og svo við höfðum áður. Eftir að við framkvæma það SQL fyrirspurn, höfum við á þessu. Við höfum bætt við Kramer og Babs Kramer að mamma borðinu. Svo það er að setja. SELECT er það sem við notum til að draga Upplýsingar frá borðinu. Svo er þetta hvernig við komumst upplýsingar út úr gagnagrunninum. Og svo að velja skipanir eru að fara að vera mjög oft notað í forritun. Almenna framework-- sem Almennt beinagrind lítur svona út. Veldu safn dálka frá borð, og síðan mögulega þú getur tilgreint condition-- eða það sem við köllum yfirleitt umsögnina, er yfirleitt hugtakið sem við notum í SQL. En það er í rauninni það sérstaklega raðir þú vilt fá. Ef þú vilt, í stað þess að fá allt, minnka það niður, þetta er þar sem þú myndir gera það. Og þá mögulega, getur þú einnig til einhvers af tiltekinni dálki. Svo kannski þú vilt hafa það raðast í stafrófsröð miðað einn dálk eða stafrófsröð byggt á annan. Aftur, hvar og ORDER BY eru valfrjáls. En þeir líklega vera useful-- sérstaklega HVAR verður gagnlegt að þrengja niður svo þú ert ekki fá allt gagnasafn aftur og að vinna það, þú færð bara stykki af því sem þér þykir vænt um. Svo til dæmis, ég gæti langað til að velja Kennitölu og fullname frá notendum. Svo hvað gæti þetta líta út? Svo er hér notandi mitt borð. Ég vil velja idnum og fullname frá notendum. Hvað er ég að fara að fá? Ég ætla að fá þetta. Ég vissi ekki að þrengja það niður, svo ég er fá kennitölu fyrir hverri umf og ég er að fá fullt nafn frá hverri umf. OK. Hvað ef ég vil velja lykilorð frá notendum WHERE-- svo nú Ég ætla að bæta ástandi, a predicate-- þar idnum er minna en 12. Svo hér gagnasafn minn aftur, notendur mitt borð efst. Hvað er ég að fara að fá ef ég vil velja þær upplýsingar, lykilorð, þar ID notandi eða idnum er minna en 12? Ég ætla að fá þetta upplýsingar til baka, ekki satt? Það gerist að idnum er 10 minna, en 12, kennitölu 11 minna en 12. Ég fæ lykilorðið fyrir þá raðir. Það er það sem ég bað um. Hvað um þetta? Hvað ef ég vil velja stjörnuna á mamma borð þar notendanafn jafngildir Jerry? OK, veldu stjarna er sérstakt konar villtur nafnspjald svokallaða sem við notum til að fá allt. Svo þeir eru að segja valið username kommum móður, sem varð að vera eina tveir dálkar í töflunni, Ég get bara valið stjörnuna og fá allt þar sem notandanafn jafngildir Jerry. Og svo er það það sem ég vildi fá ef ég gerði þessa tilteknu fyrirspurn. Nú, eru gagnagrunnar af því að þeir leyfa okkur að skipuleggja upplýsingar kannski svolítið betur en vér gæti annars. Við gerum ekki endilega að geyma öll mikilvæg stykki af upplýsingar um notanda í sömu töflu. Við höfðum tvær töflur þar. Við þurfum að geyma Nafnið allir er móður, og kannski við höfum ekki almannatryggingar númer höfum við dagsetningu þeirra fæðingu. Það þýðir ekki alltaf að þurfa að vera í sömu töflu. Svo lengi sem við getum skilgreint tengsl milli tables-- og það er þar sem það Vensla Gagnagrunnur tíma konar kemur í play-- svo lengi sem við getum skilgreint tengsl milli borðum, við getum konar compartmentalize eða óhlutbundin hlutir vegi, þar sem við höfum aðeins mjög mikilvægar upplýsingar okkur er annt um í töflunni notandans. Og þá höfum við viðbótarþjónustu upplýsingar eða auka upplýsingar í öðrum töflum að við getum tengst aftur á notendur borð á ákveðinn hátt. Svo hér höfum við þessar tvær töflur, en það er sambandið milli þeirra, ekki satt? Það virðist eins og notandanafn gæti verið eitthvað sem er til í sameiginlegt milli Þessar tvær mismunandi töflur. Svo hvað ef við höfum nú aðstæður þar sem við vilt fá fullt nafn notanda frá Borð notanda, og móðir þeirra er nafn frá móður borðinu? Við höfum ekki leið til að fá það sem það stendur, ekki satt? Það er engin ein tafla sem inniheldur bæði fullt nafn og nafn móður. Við höfum ekki þessi valkostur frá því sem við höfum séð hingað til. Og svo við verðum að kynna hugmyndin um a JOIN. Og tengir eru sennilega mest complex-- það er í raun mest flókin aðgerð við erum að fara að tala um í myndbandinu. Þeir eru svolítið flókið, en þegar þú fá the hanga af það, þeir eru í raun ekki svo slæmt. Það er bara sérstakt tilfelli af a velja. Við erum að fara að velja safn af dálkum úr töflu þátttakendurnir í öðru borði á einhverjum umsögnina. Í þessu tilviki, að hugsa um það eins og this-- Taflan einn er einn hring hérna, borð tveimur er annar hringurinn hérna. Og sú umsögn hluti í miðju, það er tegund af eins og ef þú heldur að um sem Vennmynd, hvað þeir hafa sameiginlegt? Við viljum tengja þessar tvær töflur miðað við það sem þeir hafa sameiginlegt og búa til þessa tilgátu töflu sem er samruni tveggja saman. Þannig að við munum sjá þetta í dæmi og kannski sem mun hjálpa hreinsa það upp smá. Svo kannski þú vilt velja user.fullname og moms.mother frá notendum liðs í mamma borð í hverri stöðu þar sem notandanafn dálk er sú sama á milli þeirra. Og þetta er ný Setningafræði hér, þennan notanda. og mamma .. Ef ég er að gera margar töflur saman, get ég tilgreint borð. Ég get greina, einkum um sem á á mjög botn þar. Ég get greina notandanafn dálki á notenda töflu frá notendanafni dálki mamma borð, sem eru otherwise-- ef við sögðum bara notandanafn jafngildir notandanafn, sem gerir í raun ekki meina neitt. Við viljum gera það þar sem þeir passa. Þannig að ég get tilgreina borðið og dálk nafn í tilfelli af aðstæðum þar sem það væri óljóst hvað ég er að tala um. Svo það er allt sem ég er að gera það er að ég er segja þennan dálk frá þessari töflu, og að vera mjög skýr. Svo aftur, ég er að velja fullt nafn og nafn móður frá notenda töflu tengd saman með moms borð í hverri stöðu þar sem þeir deila því column-- þeir deila því notandanafn hugmynd. Svo hér eru töflur sem við höfðum áður. Þetta er ástand okkar gagnagrunnur eins og hún er núna. Upplýsingarnar sem við erum útdráttur er þetta til að byrja með. Þetta er ný borð við erum að fara til að búa til að sameina þessar saman. Og eftir að við erum ekki að leggja áherslu Róður Newman í töflunni notandans, og við erum ekki að leggja áherslu Róður Kramer í mömmum töflunni vegna þess að hvorki er til staðar í bæði sets-- í báðum borðum. Einu upplýsingarnar sem er sameiginlegt milli þeirra er Jerry er í báðum töflum og gcostanza er í báðum borðum. Og svo þegar við gerum SQL JOIN, hvað við get-- og við að gera í raun fá þetta. Það er tegund af tímabundið breytu. Það er eins og ímyndaður Samruni tveimur borðum. Við fáum í raun eitthvað eins og þetta, þar sem við höfum sameinað saman borðum á upplýsingar sem þeir hafa sameiginlegt. Svo eftir að users.username og moms.username dálki, það er nákvæmlega sú sama. Það var upplýsingar sem var í samræmi frá notendum borð og mamma borð. Og svo við sameinaði saman. Við hent Kramer því að hann var ekki til í notenda töflu, og við hent Newman, því Hann var ekki til í moms töflunni. Þannig að þetta er ímyndaður samruna nota Join rekstur SELECT. Og þá vorum við að leita að því fullt nafn notanda og móðir notandans, og svo er þetta upplýsingar sem við myndum fá frá heildar fyrirspurn að við gert með því að velja. Þannig að við byrjuðu borðum saman og við dregin þá tvo dálka, og svo er það sem við myndum fá. En SQL tengir konar flókið. Þú verður að öllum líkindum ekki gera þeim of mikið, en bara að hafa einhverja hugmynd af beinagrind sem þú getur notað til að sameina tvö töflur saman ef þú þarf að. Síðustu tveir eru aðeins einfaldara ég lofa. Svo uppfæra, getum við notað UPDATE til að breyta upplýsingum í töflunni. Almenna snið er UPDATE sumir borð, setja nokkrar dálk til nokkur gildi Þar sem sumir eiginleikann er fullnægt. Svo til dæmis gætum við viljum að uppfæra notendur borð og stilla lykilorð til Yada BLA, þar sem kennitala er 10. Þannig að í þessu tilfelli, við erum uppfæra notendur borð. The kennitala er 10 fyrir sem fyrst röð þar, og við viljum að uppfæra lykilorð til blaðrið. Og svo er það hvað myndi gerast. Það er nokkuð augljóst, ekki satt? Það er bara mjög einfalt breyting að borðinu. DELETE er rekstur sem við notuðum til að fjarlægja upplýsingar úr töflunni. DELETE FROM borð þar sumir eiginleikann er fullnægt. Við viljum eyða frá notendur borð til dæmis þar sem notendanafn er Newman. Þú getur sennilega giska á hvað er að fara að gerast hér eftir að við framkvæma að SQL fyrirspurn, Newman er farinn frá borðinu. Svo öll þessi starfsemi, eins og ég hef sagt, eru mjög auðvelt að gera í phpMyAdmin. Það er mjög notendavænt viðmót. En það hjartarskinn þurfa handafl. Við viljum ekki að ráða handafl. Við viljum áætlanir okkar til gera þetta fyrir okkur, ekki satt? Þannig að við might vilja til að gera þetta kerfisbundið. Við viljum að fella SQL og hafa eitthvað annað til að gera þetta fyrir okkur. En hvað höfum við séð að leyfa okkur að kerfisbundið gera eitthvað? Við höfum séð PHP, ekki satt? Það kynnir sumir kraftur í áætlunum okkar. Og svo sem betur fer, SQL og PHP spila mjög vel saman. Það er aðgerð í PHP kallast fyrirspurn, sem hægt er að nota. Og þú getur framhjá sem breytu eða rök fyrirspurn SQL fyrirspurn sem þú vildi eins og til að framkvæma. Og PHP mun gera það fyrir þína hönd. Svo eftir að þú hefur tengt við gagnagrunninn með PHP, það er tvær prófkjörum þú gerir þetta. Það er eitthvað sem kallast MySQLi og eitthvað sem kallast PDO. Við munum ekki fara inn a gríðarstór upphæð smáatriði þar. Í CS50 við notum PDO. Eftir að þú hefur tengt við gagnagrunninn, þú getur þá gera fyrirspurnir gagnagrunninn við brottför fyrirspurnir sem rök að PHP virka. Og þegar þú gerir það, geyma þú að niðurstaða sett í tengin array. Og við vitum hvernig á að vinna með tengin fylki í PHP. Svo ég gæti sagt eitthvað eins this-- $ results-- þetta er í PHP-- jafngildir fyrirspurn. Og þá innan í fyrirspurn virka sem rök að ég er liggur við fyrirspurn sem lítur út eins SQL. Og í raun það er SQL. Það er fyrirspurn band sem ég myndi eins og til að framkvæma á gagnagrunninum mínum. Og svo í rauðu, þetta er PHP. Þetta er SQL sem ég samþætta inn í PHP með því að gera það rök við fyrirspurn virka. Ég vil velja fullname frá notendur þar kennitala jafngildir 10. Og þá kannski eftir að ég hef gert það, Ég gæti sagt eitthvað eins og þetta. Ég vil að prenta út skilaboð Takk fyrir að skrá þig inn. Og ég vil það interpolate-- Ég vil að interpolate $ niðurstöður fullname. Og svo er það hvernig ég vinn með sem tengin array sem ég fékk til baka. $ Niðurstöður fullname myndi grundvallaratriðum endað prenta út, takk fyrir að skrá þig inn, Jerry Seinfeld. Það var fullt nafn þar idnum jafngildir 10. Og svo allt sem ég er að gera er ég now-- ég geymt fyrirspurn mín, niðurstöður fyrirspurn minni og úrslit í tengin array, og fullname er nafn dálkurinn ég var að fá fyrir. Svo er það lykillinn minn í niðurstöðum tengin array sem ég vil. Svo Takk fyrir að skrá þig inn, $ niðurstöður, fullname mun prenta út, mun standa rétt á milli þessara hrokkið axlabönd, Jerry Seinfeld. Og ég eins og að prenta út skilaboð Takk fyrir að skrá þig inn Jerry Seinfeld. Nú, sennilega við viljum ekki að erfitt kóða hlutir eins að í, ekki satt? Við might vilja til að gera eitthvað eins og prenta F, þar sem við getum komið í stað og kannski safna mismunandi upplýsingar, eða kannski hafa fyrirspurn ferli mismunandi upplýsingar. Og svo fyrirspurn, fyrirspurn virka hefur Þessi hugmynd um tegund af punktbreytingar mjög svipuð að prenta F prósent s og prósent c, er spurningarmerki. Og við getum notað spurningu markar mjög hliðstæðri að prenta f að skipta breytum. Svo kannski notandi skráður inn fyrr, og þú vistaðir notandi kennitölu í $ _session PHP frábær alþjóðlegt helstu ID. Svo kannski eftir að þeir innskráður, þú stillir _session $ ID jafngildir 10, framreikna frá dæminu við sáum bara annað síðan. Og svo þegar við afgreiðum í raun þetta fyrirspurn niðurstöður núna, það myndi stinga í 10, eða hvað the $ _session ID gildi. Og svo að leyfa okkur að vera aðeins meira dynamic. Við erum ekki erfitt erfðaskrá hluti í lengur. Við erum að vista upplýsingar einhvers staðar og þá við getum notað þær upplýsingar aftur til konar alhæfa hvað við viljum gera, og bara stinga í og ​​breyta hegðun síðunni okkar miðað við það sem kennitölu notandans reyndar er eftir að þeir hafa innskráður. Það er líka hægt, þó, að niðurstöðurnar sett gæti samanstanda af mörgum röðum. Í því tilviki, þú þarft fjölbreytta arrays-- fjölbreytta tengin fylki. Og þú þarft bara að árétta í gegnum það. Og við vitum hvernig á að árétta gegnum array í PHP, ekki satt? Svo hér er líklega flókið hlutur sem við höfum séð hingað til. Það samlaga raun Þrjú tungumál saman. Hér í rauðu, þetta er einhver HTML. Ég er greinilega starting-- þetta er bút af einhverju HTML sem ég hef. Ég er að byrja nýja málsgrein sem segir mömmum af Seinfeld TV. Og þá strax í kjölfarið Ég er farin borð. Og þá eftir að ég hafa sumir PHP, ekki satt? Ég hef allan PHP kóða í það. Ég greinilega að fara að gera fyrirspurn. Og til að gera fyrirspurn, ég ætla að vera með SELECT mæður FROM mömmum. Þannig að þetta er getting-- þetta er SQL. Svo bláa er SQL. Rauði við sáum annað síðan var HTML. Og græna hér er PHP. Þannig að ég ætla að gera fyrirspurn að gagnagrunninum mínum, ég er að velja allt í mæður í moms töflunni. Ekki bara minnka það niður í lagi róður, ég ætla að biðja fyrir þeim öllum. Þá er ég að athuga hvort niðurstaðan er ekki jafngildir jafngildir rangar. Þetta er bara mín leið til að stöðva svona af ef niðurstöður eru ekki jafn null, að við myndum sjá c td. Í grundvallaratriðum er þetta bara að skoða að gera viss um að það fékk reyndar gögn aftur. Vegna þess að ég vil ekki að hefja prentun út gögn ef ég gerði ekki fá nein gögn. Þá fyrir hverja niðurstöður sem leiðir til þess að framhandleggur setningafræði úr PHP, allt sem ég er að gera er að prenta út $ útkoma mæður. Og svo ég ætla að fá að setja af öllum mæðrum each-- það er fylki af tengin arrays-- og ég prenta út hver sem eigin röð þess á borð. Og það er í raun frekar mikill allur there er til það. Ég veit að það er lítið bita gerast hér í þessu síðasta dæmi með fylki af arrays-- fylki af tengin fylki. En það raunverulega hjartarskinn bara sjóða niður í SQL til að gera fyrirspurn, yfirleitt velja eftir að við höfum nú þegar setja upplýsingar í töflunni, og þá bara draga það út. Og þetta er að við myndi draga það út í þessu tiltekna tilfelli. Við viljum vinna alla einstaklinga mæður frá moms borðið. Við fengum allt sett af þeim, og við langar að iterate gegnum og prenta út hver og einn. Svo aftur, þetta er sennilega flókinn dæmi við höfum séð af því að við erum að blanda þrjú mismunandi tungumál saman, ekki satt? Aftur höfum við HTML hér í rauðu, blandað með nokkrum SQL hér í bláum, blandað með nokkrum PHP í grænu. En allir þessir spila vel saman, það er bara spurning um að þróa góða siði svo að þú getur fengið þeim að vinna saman eins og þú vilt. Og eina leiðin til að virkilega gera það er að æfa, æfa, æfa. Ég er Doug Lloyd, þetta er CS50.