>> Molt bé.
Així, sense més preàmbuls, SQL, Structured Query Language.
Així que, probablement acostumat a aquest menys en CS50, potser en CS165,
potser en la seva pròpia projectes personals.
I què és SQL et deixa fer, en un SQL Server de manera més general?
Sí?
[Inaudible Observació]
Bé, això va ser molt manera segura de dir-ho.
Sí Per tant, permet emmagatzemar dades
i permet més important realitzar consultes de dades.
I aquest és un pas endavant
des de l'ús d'alguna cosa més simple com un fitxer CSV, és clar.
Variables separades per comes.
Valors similars.
De la mateixa manera li permeten guardar informació d'una fila
en un arxiu de text.
Però quin és l'inconvenient d'un CSV per emmagatzemar les seves dades,
tot i que efectivament obtenir les files i columnes d'ell?
Sí
>> No 'té de la mateixa organització
eficiència [inaudible].
>> No té la mateixa eficiència organització.
Què vols dir?
>> Bé, com [inaudible] tenen com a principal [inaudible].
>> D'acord. Sí
>> És una base de dades relacional vostè pot tenir diverses bases de dades
vinculats l'un a l'altre de formes molt específiques.
>> D'acord. Bé.
>> És [inaudible] per configurar un fitxer CSV.
>> I m'ho dius a mi modificar una mica de terminologia.
Així diverses taules dins d'una base de dades, segur,
i que va més enllà del que es pot fer amb un sol fitxer CSV.
Però en realitat la limitació amb CSV jo diria és
que la ineficiència de tot.
És molt fàcil de disseny.
Però si vostè vol fer un consulta, el que és el temps d'execució
de qualsevol consulta de selecció en un arxiu CSV?
Vull dir que és gran i vell [inaudible], bé, perquè en el pitjor dels casos,
es van aixecar a la part inferior.
Fins i tot si s'hagués ordenat el conjunt Arxiu CSV, si vostè no sap
que per avançat, bé, vostè encara va a tenir
Cerca en tot l'assumpte.
Així, entre les coses aconseguirem
l'ús d'un real base de dades utilitzant un llenguatge
com SQL és que podem consultar i el que puguem per avançat
com els dissenyadors de bases de dades especifiquen quins són els camps
que probablement es tindrà preguntes sobre el que la gent
en MySQL o Microsoft o Oracle,
qui ha fet de la base de dades que utilitzeu es pot fer tot
de l'àrdua tasca de esbrinar, OK,
donat un milió d'aquests IDS.
Com podem Layout - a terme a la memòria?
Una espècie d'arbre estructurar potser,
de manera que quan vostè fa realment executar Select,
que és una cosa que és logarítmic o logarítmic
d'logarítmica en el temps en lloc que en realitat delegant
en alguna cosa lineal.
Així que ens van donar una gran quantitat de rendiment d'aquesta manera.
I també podem emmagatzemar molta més dades més fàcilment perquè l'SQL
Server s'emmagatzema normalment en la memòria RAM tot i que les parts
que podria ser emmagatzemat en el disc i vostè probablement sap per ara
que la memòria RAM és generalment més ràpid que els discos,
així que això és una bona cosa.
I també podem gestionar concurrència molt millor.
Si vostè ha pres 165 o 161, vostè sap que si dues persones tracten
a fer el mateix alhora en un sistema,
coses dolentes en general, pot succeir.
Així entre les altres característiques que pot obtenir si dissenyem les nostres taules
de la manera correcta és millor suport i seguretat
quan es tracta de concurrència.
Així, dues persones en dues parts
del món a través de la mateixa lloc web, si tots dos intenten
comprar alguna cosa en el mateix temps, que l'ordre no va
per anar en forma simultània.
D'alguna manera ells poden serialitzar per algú que no sigui la nostra -
algú que no sigui nosaltres mateixos.
La voluntat de bases de dades fer això per nosaltres.
Així que quan la seva forma més simple,
SQL ens permet una consulta base de dades relacional.
Una base de dades relacional és un que en té un
o més taules en ella normalment.
I si això és un poc desconegut,
vostè pot realment pensar en això com Excel o números
o fulls de càlcul Google.
Només té files i columnes i en general la part superior de cada
de les files té un nom per a ell.
Així que aquest podria ser el ID columna, la columna nom,
la columna de la direcció i així successivament.
I llavors vostè pot tenir múltiples aquestes taules si desitja
per començar a traçar diferents tipus de dades.
Però vostè pot recordar com a mínim des CS50 que intentem
per donar-li una interfície gràfica d'usuari basada- eina [inaudible]
per gestionar la seva base de dades.
Es deia phpMyAdmin.
Així que és només una coincidència que va ser escrit en PHP, en realitat,
però era just basat en la web una acabar davant una base de dades.
I a través de les diferents pestanyes i enllaços, podria començar
per configurar una base de dades per si mateix.
Però una bona eina per començar a aconseguir una mica més còmode
amb és també el client de línia d'ordres.
Per tant, si s'utilitza l'aparell CS50 o en realitat amb qualsevol PC macro
que té una línia d'ordres de MySQL client, també pot fer-ho espècie
de la vella escola, com aquest.
Com acotació al marge del projecte MySQL, almenys la versió de codi obert
que ara es diu MariaDB per diversos motius pots llegir
a la Viquipèdia, però que és el mateix programari,
que és la mateixa sintaxi i així successivament,
més o menys la mateixa base de codi.
I així, quan estic a l'est Prompt ara puc interactuar
amb la meva base de dades molt més manualment.
Així exemple d'això, m'ho dius a mi anar per davant
i acaba d'obrir una finestra de terminal.
Em va passar a utilitzar el CS50 Appliance, però vostè pot fer això
en la majoria de qualsevol sistema en que vostè té el dret
programari instal · lat.
I jo faré MySQL-o per nom d'usuari John Harvard
en aquest sistema en particular, p- una contrasenya que vaig escric
en una mica més segura colpejant Retorn.
Ara estic em demana.
Vaig a escriure carmesí al Appliance CS50
i ara veig essencialment que la mateixa pantalla.
Però hi ha ordres ara que podem començar a escriure
com mostrar les bases de dades, i que em va a mostrar tot
de les bases de dades que tinc ja creats al sistema,
més o menys la mateixa llista pots veure en phpMyAdmin.
Hi ha un parell d'altres com esquema d'informació i de proves,
que si treus el cap al voltant del CS50 Appliance, que amaga alguns
d'aquestes taules de nivell inferior
però han estat allà tot aquest temps.
MySQL en realitat té baix nivell propietats com noms d'usuari
i les contrasenyes de la base de dades si mateix, no per a la seva aplicació
que és possible que que s'executa en la part superior de la mateixa.
Així que per endavant, avui, creat un parell de bases de dades,
un dels quals es diu courses50.
El més probable és que alguns de vosaltres heu utilitzat Eina de compra suposat CS50,
que és una gran interfície per catàleg de cursos del registrador.
I això és en realitat una bona conjunt de dades que parlar perquè,
un, que som una espècie de tot òbviament familiaritzats amb cursos
i els instructors i reunions llocs i tota la classe
de les coses ordinàries de la universitat,
però també té una mica de oportunitats interessants
per al disseny.
Així que pensem que usaríem la noció d'un catàleg de cursos
i una eina comercial com exemple al llarg d'avui per ordenar
d'emmarcar alguns dels dissenys decisions que hem de prendre.
Així que anem a començar per aquí.
Suposem que jo realment volia per representar la súper simple
per descomptat, les compres d'eines.
I el món més simple M'imagino i un és
en què hi ha cursos i hi ha instructors.
I suposem que bé de la discussió
que cada curs té almenys un nom.
Així que anem a començar a dibuixar això.
Vaig a utilitzar phpMyAdmin només per motius de comoditat,
així que no hem d'escriure totes les consultes de forma manual.
Però aquí estic, al meu base de dades courses50.
Si no està familiaritzat amb aquest, que va a ser molt fàcil una vegada que et submergeixis
al seu propi projecte si voleu utilitzar-lo.
Vaig a crear una taula anomenada Cursos
i només puc pensar d'un camp
per ara, el nom d'un curs.
Vaig a seguir endavant i diguem donar-me una columna.
Ara, en recordar a obtenir una interfície que és una mica
com aquest.
I l'altra boca francament de phpMyAdmin és que una espècie
d'auto-instrucció i que a través dels menús desplegables, pot ordenar
de veure el que la seva possible les decisions de disseny són.
Així que em vaig a donar cada curs d'un nom.
Aquest és el nom d'aquesta columna.
I què hi ha del seu tipus de dades?
La majoria de vostès han de saber a menys alguns d'aquests tipus de dades
de l'experiència prèvia.
El que és apropiat per nom del curs?
Sharon?
>> VARCHAR.
>> Acceptar, varchar que és variable char.
I el que fa que significar més tècnicament?
[Inaudible Observació]
D'acord. Així que és una cadena.
I l'aspecte var del que implica?
Variable. Però el que Què significa això?
Sí?
[Inaudible Observació]
Exactament. Així que és una variable nombre de caràcters
a la cadena fins fins a cert màxim.
Així que aquí està la nostra primera decisió de disseny.
De fet, hem de decidir quants bytes com a màxim
assignar a cadascuna d'aquestes cadenes.
En termes generals, vol espècie de no fer-ho massa petit,
ho faci massa gran 'Causa òbvia
si és massa petita no ets més que començarà a truncar les dades de
i si no es perden dades.
I si és massa gran, no ets més que espècie de dir la base de dades
a esperar i optimitzar per a més dades
del que podria de fet alguna vegada.
Llavors, què és un sentiment raonable nombre del nom d'un curs?
60? OK, així que 60.
Això sembla bastant raonable
sempre és que no hi excepcions a això.
En realitat no hi ha dur, regla fixa.
Per ser honest, per raons històriques molt
de la gent triarà 255 Perquè des de fa anys que era una espècie
del màxim predeterminat utilitzant 8 bytes - 8 bits com el seu comptador.
M'agradaria més [inaudible] podria utilitzar potències de 2
però és una espècie d'importància.
Així que podem anar amb 60.
Això sembla raonable, sempre
ja que amb el temps no em penedeixo Perquè això és una fita superior.
Ara, suposem el contrari havia pres una decisió,
chars no variable, però només el camp de caràcters.
Així que a diferència de C i C + +, carbó de llenya no vol dir que hi ha un caràcter
i bases de dades que generalment significa un nombre fix
de caràcters d'una cadena.
Quina seria la boca i / o desavantatge de la meva elecció de 60
per a un camp char, en lloc de varchar?
Aquesta és exactament la primera classe de la decisió que haurà de fer
en inspeccionar [fonètic] fora de projectar amb els seus socis.
Sí, Sharon de nou.
[Inaudible Observació]
Bé. Així que si el nom és menys
de 60 llavors vostè està perdent el que el delta és
entre 60 i el longitud real.
Així que només se sent un malbaratament, més bytes que vostè necessita.
Però, per què existeix?
Segurament hi ha algun revés.
Sí?
[Inaudible Observació]
Clar. Així que de vegades podria saber el nombre fix
de personatges com 10 dígits un número de telèfon, per exemple.
Però a qui li importa, com per què No acaba de dir l'11 de totes maneres
o per què no dir-ho 60 de totes maneres amb el varchar?
Quin avantatge Com arribem coneixent i dissenyar
per a un nombre fix de caràcters?
[Inaudible Observació]
Estàs en el camí correcte.
Pel que és l'optimització, però que és realment de - si?
[Inaudible Observació]
D'acord. Bé. Anem enfocament en l'última part.
Així indexació.
Així que resulta si saber per endavant que tot
dels seus camps es van a ser de 60 caràcters,
realment es pot pensar en aquest la columna a la base de dades d'Excel
com tenir molt recte, justificat a l'esquerra
i les vores rectes justificats
perquè cada columna és de 60 caràcters d'amplada.
Això vol dir que aquesta cadena és de 60 caràcters de distància
d'aquesta cadena, 60 personatges allunyats d'aquest
i aquest i aquest.
Pel que només vol tornar al après C, que va tenir accés aleatori
en el món de les matrius, mateixa idea aquí.
Si es representa la columna usant caràcters de longitud només fixos,
vostè pot efectivament índex a l'atzar a 60 o 120 o 180
i es pot obtenir en forma individual cordes molt més ràpidament.
Llavors, si en canvi, la seva columna tenia una vora recte esquerre per dir-ho
sinó un dret molt accidentat la vora de la columna
perquè és possible que tenir 10 caràcters,
15 caràcters, 5 caracters.
Així que això també és una solució de compromís.
I de vegades només a través de l'assaig i error
i l'experimentació pot vostè imaginar
el que realment la decisió correcta no és més que aquests són els tipus
de preguntes que ha d'anar
a través de les seves ments i / o taules quan arriba el moment
el disseny de la base de dades.
Per tant, no necessàriament dret respondre, però que hauria de
almenys tenir algun frase o dues en ment
fer còpies de seguretat ho decisió que prenguis.
Està bé.
Així que anem a mantenir el desplaçament en les instruccions aquí
que són la interfície d'usuari de phpMyAdmin.
Per tant, el valor predeterminat per un nom, he especificar
que ha de ser té un valor predeterminat de null?
Què pensa vostè?
Pot un suposat tenir un nom nul?
Només sembla estrany, oi?
No puc pensar en cap cursos identificats a Harvard.
I potser hi ha una mica de cas fosc racó
, Quan un curs se li dóna un nombre
i el professor no té triat un nom per a ell, però -
Vull dir, al diable amb això,
com anem ni tan sols molesti donar suport això.
Jo diria que en l'interès d'una bona base de dades neta,
anem a especificar que no es pot tenir un valor predeterminat de null.
Alternativament, podríem fer alguna cosa com descomptat sense títol
que no és diferent amb Mac OS i Windows fer
quan es crea un carpeta, per exemple,
però cal fa una mica més de sentit
pel que l'ésser humà veure alguna cosa.
Estem parlant d'un base de dades back-end, presumiblement,
de catàleg de cursos.
Així que realment no em fins i tot com la idea de donar-li
en els noms dels cursos sense títol
ja que això no és realment ajudarà a ningú.
Així que anem a deixar això com cap, el que significa que quan s'insereix
en aquesta base de dades, vostè té per donar a cada curs d'un nom
que se sent una mica netejador per a mi.
Està bé.
Així que desplaçar-se més lluny, la confrontació.
Això només té a veure amb jocs de caràcters i altres coses
si alguna vegada has vist mencions de Sueca
phpMyAdmin és Perquè la gent
qui va escriure phpMyAdmin fora de Suècia.
Això és PHP o és MySQL?
Un dels dos, oblidar brusc.
Però és per raons històriques
però vostè pot expressar cada caràcter en Anglès
que pugui fer-ho amb sueca pel que és en gran part un problema inexistent.
El CS50 Appliance tot i que és utilitzat - configurat per utilitzar UTF-8,
pel que en general ha no obrirà per a vostè.
Atributs.
Així que cap d'aquests són realment rellevant aquí.
Veig binari, sense signar, Zerofill sense signe,
i en l'actualització de marca de temps actual.
Aquest camp només s'aplica per algun camp numèric
o alguns camps d'hora.
Així que ens saltarem sobre que en la seva totalitat.
Null. Pot aquest camp sigui nul?
Així que no. Ja tenim aquest tipus de converses.
Així que no volem un valor predeterminat.
Nosaltres no volem que sigui nul.
Què passa amb l'índex?
Hi ha quatre opcions aquí.
Què significa si especifiquem
que aquesta fila es va ser una clau principal?
Pensant en CS50 o CS165 si vostè ha pres ell.
[Inaudible Observació]
Exactament. Així que una clau principal per definició, és el camp
que identifica de cada fila d'aquesta taula.
I vostè pot confiar en ell per fer que la identificació única.
Així que, què significa després simplement ser únic?
Bé, una mica d'aquests dos té sort
de baix implicacions sota de la caputxa.
Però en general, la clau principal és una mena de contracte que vostè faci
amb la cosa de la base de dades.
Quan faig consultes a la recerca d'un curs,
Vaig a utilitzar aquest camp particular.
I tornarem a pel que podríem tenir dos
aquestes opcions aquí, primària o única.
Unique només diu, aquesta camp serà únic
però jo no estic fent cap tipus de compromís verbal aquí
per utilitzar aquest camp fer les meves recerques
per raons que veure en un moment.
Si especifiquem en lloc d'índex, Què significa per especificar
que un camp té un índex sobre el mateix?
Sí?
[Inaudible Observació]
Exactament. Ha estat optimitzat per a la consulta.
Així que - servidor de base de dades, Oracle, MySQL, el que sigui,
generalment treballar la seva màgia darrere de l'escena una vegada que feu clic
aquesta opció i feu clic a Guardar i es construirà
en general una estructura d'arbre, Arbres B si vostè ha vist
o escoltat a part que és un arbre molt curt buscant
això et dóna molt bé propietats logarítmiques
en la recerca de les dades.
Si no s'especifica un índex en un camp, què està passant
en ser el funcionament temps de recerca
per a una arbitrària [Fonètic] Nom del curs?
Què és això?
[Inaudible Observació]
Oh, [inaudible], lineal, no?
Si no hi ha optimitzacions atorgada a la base de dades
i vostè no ha pensat la base de dades de quin tipus
de les dades per esperar.
El millor que pots fer és xec sobretot quan s'està buscant
per a un cert valor, especialment si no pogués
de fet ser duplicats.
De text complet mentrestant, anem a agitar les nostres mans per ara.
Però, en general, aquest és un tipus d'índex que permet
per optimitzar la paraula clau busca en un camp.
Així que això podria ser un bon candidat
per com una descripció del curs on és possible que tingui un parell
de paràgrafs i vostè pot ser voler fer coincidències de subcadenes.
De text complet en general deixa ho fas bastant eficient.
AI, es tracta d'una espècie de sinistre de l'explicació, però si passem per
sobre ella veuràs Increment automàtic.
No és aplicable tant aquí però increment automàtic és útil
per com camp d'un int perquè la base de dades es farà càrrec
del procés de més plusing que cada vegada que fas una inserció.
Així que, encara que dues persones literalment, feu clic a Envia
al mateix temps i tractar per crear una fila d'alguna manera
a la base de dades, un ells aconseguiran el número I,
l'altre serà aconseguir el nombre més 1.
Vostè no ha de preocupar
prop de dos nombres que són assignat de forma idèntica si fossis
fer-ho vostè mateix en el codi.
Està bé.
Així que una mica com quan tenim un nom per a ser.
Així que anem a fer clic a Desa.
És aquest un bon disseny per a una taula de base de dades?
I en un part si oxidat en SQL o espècie
tot just giri sempre una persiana ull al que estava passant,
Jo podria haver escrit exactament això -
aquestes tres línies en aquest símbol blanc i negre
en la línia d'ordres client o que podria haver fet
que en el codi de programació.
Així que tot phpMyAdmin està fent per mi, és només que em estalvia l'esforç
de recordar de vegades el sintaxi i escriure per
com ordres tediosos.
Està bé.
Així que això no se sent com el millor disseny, una taula de camp un.
Ara podríem tenir coses com a professors
i locaciones i descripcions.
Però fins i tot llavors, l'ús només de nom
per identificar cursos no se sent ideal.
El que generalment tenen hem fet en el passat
si ha utilitzat les bases de dades de forma única les files?
No usar varchars normalment.
Sí?
[Inaudible Observació]
Sí Així que en general un ID de golf.
Per tant, la més comuna apropar aquí, sobretot
quan s'utilitza un marc en realitat és només
per utilitzar un nombre com un nombre enter.
Així que permetin-me anar endavant i fer això.
I podem fer-ho a uns pocs maneres, però previ avís si el zoom
en el fons aquí.
Vaig a dir afegiu columnes a l'extrem de la taula,
generalment només per visual conveniència de posar IDs
en el principi de la taula tot i que això no té cap veritable
impacte funcional.
Així que vaig a dir afegir 1 columnes
en el principi de la taula.
Vaig a fer clic a Vés, que em fa l'esquena aquesta interfície d'usuari aquí.
Anem a trucar a aquest ID.
Si pensem que tindrem hi ha més coses 4.000.000 cursos
camp d'un int està molt bé.
Fins i tot podríem reduir
però l'espai és barat pel que realment li importa.
Però, estem tractant de escriure Facebook ara,
podria no ser una mala cosa anticipar grans ints
el que ens donaria sencers de 64 bits
però llavors vostè està, literalment, duplicant el nombre de bits
que utilitzeu, tan menor compensació
però és una cosa a tenir en compte.
Ara, aquest és un confús El llegat.
Vostè pot ser que recordi l'ús de MySQL
que cada vegada que es declara un int camp que sovint va a veure un nombre
al seu costat, com el número 10.
No té res a veure amb la mida del nombre
o el nombre de bits.
Això té a veure amb el nombre de caràcters que s'utilitzen
visualment pantalla aquest camp int
quan s'utilitza una finestra de terminal.
Així podem veure que en un moment.
Per tant, no es deixi enganyar introduint números
allà, tot i que és efectivament demanar-nos
1 aquí.
Aquí, vaig a seguir endavant i dir sense signar.
No hi ha raó per a deixalles tots els nostres números negatius
des de la base de dades en general, es va
assumir positiu valors o nul · la.
L'ID definitivament no ha de ser nul.
I què pensa vostè sobre l'índex per a aquest camp ID?
Fem-ho primària.
Així que, què passa si, però, com el que pugui només pensar en un curs CS164
a Harvard i només un Per descomptat CS50 a Harvard
i això és bastant molta veritat en general
que hi ha potser excepcions [Inaudible] els dos semestres
o alguna cosa estranya com això.
Però més fonamentalment, per què és millor
utilitzar un integrant ID numèric a identificar de manera única cursos més
que una cadena única?
Sí?
[Inaudible Observació]
Bé, interessant.
Així que si teníem sort de cursos de cross-llista.
Així que això és un bon exemple.
No estic segur que ho faria resoldre que, encara que
donant-los la mateixa Número d'identificació, si això és
on vostè anava amb això.
No? D'acord. Però sens dubte un cas cantonada a considerar.
Si hi ha una mena de - necessitem algun tipus
d'aliasing potencialment.
[Inaudible Observació]
Clar.
[Inaudible Observació]
Això és un bon exemple.
El nom pot canviar amb el temps, totalment raonable.
Què més?
[Inaudible Observació]
Ho sentim, dir de nou.
[Inaudible Observació]
Sí, exactament.
Així que en realitat, això és el veritable factor decisiu és
que l'ús d'una de 32 bits int és Probablement serà més ràpid
d'alguna variable camp de caràcters de longitud.
En el primer cas, la llauna cabre literalment en un registre,
per no parlar de molt més menor consum de memòria.
En aquest últim cas, vas a haver de fer resort [fonètic]
per a les comparacions de cadenes que en si mateixos amb el lineal
en la mida de la cadena potencialment.
Així que és només un bon optimització,
i en particular es va
per deixar-nos fer el que es diu S'uneix de forma més eficient
en un moment.
Així que anem a fer això.
Anem a especificar que aquest és primària
perquè jo particularment no volen tenir cura o pensar
sobre el que el nombre és d'un curs.
Que prenguin en qualssevol valors que volen.
Jo diré d'increment automàtic així que puc externalitzar aquest detall.
Igual que en una banda vostè pot ser saber que la Universitat de Harvard
almenys té únic nombre de cursos.
No tinc cap record el que aquests cursos s'ofereixen.
Sé que de CS50 nombre de catàleg és 4949,
completament arbitrària.
Però no és estrany casos extrems en què fins i tot
a l'abocador registrarial per descomptat, les dades del catàleg,
de vegades, els cursos, els vells els cursos tenen un nombre similar abril.
Però tècnicament que camp és un camp de caràcters
que simplement comença amb 0004.
Així que aquí també, vostè ha d'estar compte amb distingir
entre coses com un Per descomptat el nombre de catàleg
que podria tenir algun humà noció de longitud fixa, 0004,
i no s'ha d'emmagatzemar que, per exemple en un ints.
Aquest tipus de camp ha ser emmagatzemada en un altre lloc.
Així que a Harvard, si tinguéssim realment fer un curs
eina de compres, és probablement no és suficient
als cursos de nombres amb només 1, 2, 3, 4.
Probablement tindrem
tenir un altre camp anomenat nombre de catàleg,
que també se suposa de basar única
en les convencions humanes aquí però no és la millor opció
per un identificador únic perquè podria ser de longitud variable.
Potser no és de quatre caràcters, podria ser 5.
De fet, crec que uns pocs Fa anys que es mouen
a causa cinc personatges hi van ser més de 999 cursos
en total, o alguna cosa així això, o 9.999 cursos.
Així que, això podria ser un exemple en el que el camp no és primària
però ha de ser únic.
I l'adreça de correu electrònic és un altre.
És possible que vulguis que sigui única
però no necessàriament la seva clau primària.
Està bé.
Així que permetin-me colpejar a un altre taula molt més ràpid que aquest.
Així que vaig a trucar a aquest 01:00 Instructors i vaig
per donar a aquest un total nombre de columnes de dos.
Vaig a aprendre la meva lliçó de l'última vegada.
Vaig a trucar a la primera columna ID.
Vaig a trucar a la Nom segona columna.
Jo també faré VARCHAR.
Vaig a assumir cap professor té un nom més llarg
de 60 personatges, encara que Ara això pot ser empenyent
amb alguns noms llargs, especials persones amb segons noms.
Això està bé per avui.
Així que anem a desplaçar-se fins aquí.
Farem això sense signar de nou.
Fem d'aquest primari.
I ens permetem noms duplicats
en cas que hi hagi dos John Smith, o alguna cosa així.
I ara tenim dues taules.
Així que ara, això planteja la Pregunta Com associar
en instructor en el curs?
Em sento com que tipus de tinc davant de mi mateix
perquè si un instructor ensenya un curs,
el meu primer instint seria ser en realitat tornar
als cursos s'adonen, aquest no era una bona idea.
Permetin-me afegir realment una columna al final de la taula,
feu clic a Vés, i ho faré trucar a aquest Instructor.
I vaig a fer aquest tipus varchar i vaig a fer aquest 60.
I potser ho deixaré nul ara
en cas que el curs no té estat sense autor dins d'instructor
que de vegades passa abans termini comença i feu clic a Desa.
Quin d'aquests dissenys Què t'agrada més?
El primer en què tenim una la taula de l'instructor independent
o el segon en el qual només afegir un camp al curs?
Així que és una vincular estretament instructor del curs.
[Inaudible Observació]
D'acord. Bé. Però permetin-me fer retrocedir.
És tan simple com el que pugui només ha d'escriure el nom de la persona
en aquesta taula, com segurament això té algun valor o -?
[Inaudible Observació]
Està bé.
Bé, deixa de ser difícil aquí.
Així que permetin-me dir que aquest curs és CS51
i sé que ha ensenyat aquest any per dues persones.
Així, Henry Leitner i Jesse Tov però -
així que em vaig a posar una coma entre els dos, dreta.
Sóc bo en CSV des d'antany.
[Inaudible Observació]
Exactament, és clar.
Tan aviat com vostè recorre a alguna cosa com això,
que podria sentir raonable i es pot sentir
com això és una mica intel · ligent.
Jo sóc una mena de préstec d'una idea que ha de funcionar bé,
prestada una idea nova i tipus de combinar-los.
Estàs espècie de derrotar totalment el punt d'utilitzar la base de dades
en la causa el primer lloc " Si un dels valors
d'ús és agilitzar les recerques a causa dels diversos índexs
i taules que poden ser construït per a vostè
pel motor de base de dades en si.
Ara, si vostè vol buscar per a tots els cursos
que Jesse ensenya, ara vostè té Per a això subcadena coincident en tots els
dels camps d'instructor,
el que significa que efectivament lineal buscar de nou perquè tens
trobar aquest conjunt arbitrari dels tres personatges en qualsevol lloc
en el camp instructor precedit
dintre de tal vegada seguida per una coma.
Així que això definitivament no presagia res de bo.
Així que permetin-me anar de nou a la taula.
Déjame anar per davant de cursos, desfer això.
Vaig a anar per davant i posar aquest camp.
I si vols fer-ho manualment,
la sintaxi és ALTER TABLE cursos DROP instructor.
Així que seguirem endavant i dir que sí a això.
I tornar a aquesta idea anterior
on tinc una separada taula per instructors.
Però ara això se sent una mica com puc posar un curs
a la taula del curs i l'instructor
a la taula de l'instructor, però em d'alguna manera cal vincular els dos.
I com ho faries Proposem que ho fem?
[Inaudible Observació]
Bé. Així que anem a fer això.
I es podria anomenar a aquest taula en res la teoria.
Vaig a deliberadament digues-li com a molt
de marcs faria anomenar, entre ells,
Laravel com es veurà en un moment.
Vaig a dir-curs subratllar instructor.
Usant singular en aquesta cas per a cadascuna de les paraules
i tot en minúscules de nou, i també amb el -
després per ordre alfabètic ordenats d'esquerra a dreta.
Això és totalment arbitrària, sinó que tendeix a ser una convenció
en molts d'aquests marcs en PHP en altres idiomes.
Quantes columnes Què necessito Això és el que anomenem una taula d'unió,
per unir-se a altres dos taules junts?
Tres columnes?
Com - quins serien?
[Inaudible Observació]
D'acord. Bé. Això funciona.
I poguéssim tècnicament tallar una cantonada aquí, però molt
dels marcs, en particular el segueixen donant fins i tot aquestes files
identificadors únics tot i que semànticament la fila
que realment ens importa o les columnes que realment ens importen
sobre aquest últim són dos el que vas dir, ID del curs
i la identificació de l'instructor.
Així que anem a fer això.
Vaig a trucar a aquesta fila només ID, tal com ho vam fer abans.
Però aquest em vaig cridar suposat ID.
Aquest em truqui ID instructor.
I jo vaig a especificar que totes
d'ells estan sense signar Perquè vull
per maximitzar el meu 4 milions int rang.
Cap d'ells ha de ser nul.
Vaig a especificar que ID ha de seguir sent primordial.
I de nou, això és només una convenció,
una gran quantitat de marcs encara que no ordena
fonamentalment de la necessitat d'una identificador únic de la fila,
resulta que és convenient per el codi, l'SQL que està passant
ser automàticament generada per nosaltres.
Així que ho deixo com a primària.
Però ara, quin tipus de tenir una decisió de disseny,
ID del curs i ID instructor.
Què índexs si qualsevol en cas d'aconseguir?
Si ho deixo sense índexs, Quina és la implicació?
Què és una implicació?
Rendiment com abans, no?
Si no hi ha cap índex, la el millor que pots fer és tipus
de [inaudible] a través de la Tot això a la recerca de nombres.
Així que no se sent llest.
Hauria de ser primària?
Així que per què no?
Per què no primària?
[Inaudible Observació]
Perfect. Així que vam rodar fora [fonètic] primària.
Ja Triem això.
Així, en cas de ser únic?
[Inaudible Observació]
Bé. Per tant, si s'assumeix un instructor per descomptat,
totalment bé.
I això és sens dubte el cas comú
però ja ens despullem 1 exemple potser familiar.
CS51 té dos instructors així que estem una mica
d'ara cargolat en aquest cas.
Si ho féssim permetre només un instructor,
que podríem fer d'una manera amb la taula d'unió total,
tornar a l'anterior enfocament
i no posar el nom de la persona potser, però la identificació de l'instructor.
Si coneixes a cada curs que acaba un instructor pot tenir només
una columna.
No obstant això, la variabilitat és el que ens va ficar en problemes.
Està bé.
Així, en cas de ser únic?
No El text complet no sentir aplicable.
Com abans hem dit que això és
per com subcadena joc per a les descripcions.
Què passa amb l'índex?
Bé, l'índex és probablement el nostre millor candidat
que narra optimitzar MySQL per recerques en aquest
O jo elaboro, optimitzar per recerques o unions
com veurem en un moment
pel que són una poc més eficient
que qualsevol cosa purament lineal.
Vull acte increments d'aquest camp?
Així que no, perquè la veritable existeix element pare
en el quadre dels cursos.
Aquí és on és aconseguirà més,
a més, quan en realitat és inserida.
Aquí, tot això va per ser inserit manualment
per nosaltres presumiblement en el codi.
Així que anem a especificar simplement que tant suposat Identificació
i ID instructor ha índexs.
Ara seguirem endavant i guardar.
I ara, només per mostrar que la correspondència
entre el que és un bon Interfície amigable interfície gràfica d'usuari
i la interfície de línia d'ordres.
Deixin-me seguir endavant i fer la següent a aquest missatge MySQL.
Vaig a dir l'ús courses50
que és el nom arbitrari Li vaig donar a aquesta base de dades.
I ara, no ho sé encara Recordem el que vam fer.
Així que permetin-me Escriu xou taules
i en general, el punt i coma serà el teu amic aquí
per acabar la consulta.
I aquí està.
Així que aquí hi ha les files o més aviat les taules que tenim aquí.
Ara, m'oblido del que un curs sembla,
així que anem a descriure quins cursos i ara veig una mena d'ASCII
o qualsevol versió del phpMyAdmin estava fent
i veig que el DI és un int.
Cal octubre.
Què significa això?
Això només vol dir que quan és apareix que prendrà
fins a 10 caràcters en la finestra de terminal.
És anul · lable?
No Aquesta és la clau principal.
Pot tenir un valor per defecte?
No I extra que és especial banderes com a increment automàtic.
Així que farem un parell insercions de ràpid aquí.
Vaig a pujar a - direm.
Anem a canviar l'estat d'una diapositiva
on em mena de pre-preparo això.
Aquest és un resum a continuació, de els tres d'aquestes taules.
Ja només manualment escrit la primera ordre.
I aquí, me'n vaig anar per davant i escrigui els altres per tu.
Això és només el el estilístic.
En general, una gran quantitat de persones escriure sentències SQL en totes les tapes
i després els noms de taules i els noms de camp en minúscules,
si més no perquè tipus d'estands
quina és la seva terminologia i el que és la sintaxi de la base de dades.
Així que aquí tenim tres taules, cursos, instructors,
i cursos d'instructors.
A la diapositiva que vaig fer amb antelació, Jo no tenia el camp ID
però això no és realment una cosa dolenta en absolut.
Ens acaba de veure un tercera columna d'allà.
Si jo hagués fet això aquí?
Així que ara permetin-me proposar que fem un munt d'insercions.
Així que aquí està algunes dades, Vaig a fer més gran
Així que vaig a proposar que en els cursos,
només ens ocupem de tres cursos.
I vaig triar aquests tres Perquè són representatius
d'alguns agradable - tenen algunes propietats agradables.
CS1, CS50, CS51, es tenen cada vegada majors identificacions
però què és el que ID és totalment irrellevant.
Això és només l'ordre en què s'auto inserits per mi.
Què hi ha dels instructors?
Així que ara, perquè Henry Leitner ensenya tant CS1 i CS51,
això és una espècie d'un oportú implicació per al nostre disseny.
I Jesse ensenya CS51 i Malan ensenya CS50.
Així que ara - o més aviat es tracta d' només els identificadors únics d'aquestes persones.
I cursos i els instructors, - instructors del curs, avís aquí.
ID1 Course, Es CS1 s'ensenya
per instructor ID1 que és Henry.
ID2 Course, que em crec ser CS50 s'ensenya
per instructor ID2, que és Malan.
I a continuació, finalment, CS51, i compte que tenim dues files.
I ara aquesta és la raó per la unió taula és de gran abast que s'ensenya
per tant Henry com Jesse.
Així que això és tot fi i bo,
, Però amb prou feines puc record de la part superior
del meu cap qui és qui aquí.
Com és possible bregar amb això en el codi,
sense haver de coses de codis durs?
Bé, aquí és on SQL si comença a ser el nostre amic.
I jo vaig a proposar que podem escriure la següent.
Vaig a fer això en a prompt actual.
Deixin-me seguir endavant i inserir aquestes coses.
Així, en la taula de cursos farem exactament el que teníem un
Fa moment.
Vaig a endavant i dir, anem a inserir CS1 i CS50.
Anem a inserir una mica més files alhora, CS51.
Ara, deixa anar per davant i estalviï.
Molt bé, així que estic sol recrear el més ràpidament
com pugui les relacions que acabem de veure a la pantalla.
I així, aquí tenim Leitner, aquí tenim Malan.
Donarem a nosaltres mateixos altra fila, i Tov.
Ara m'ho dius guardar aquesta.
I ho estic fent deliberadament en el mateix ordre.
No, em vaig oblidar de donar-li aquest increment automàtic.
Vaig a corregir ràpidament aquest.
Vaig a arreglar això en el codi en línia.
Que va fracassar en un a part.
El fet que jo no podia inseriu Leitner i Malan
i Tov fracassar, perquè no ho vaig fer especificar un número d'identificació tot i que
que està esperant una i em es va oblidar de comprovar increment automàtic,
el que significa que eren tots per defecte aconseguir zero.
Però que després contradiu que propietat que hem especificat.
La clau primària es va violar de manera que ni tan sols em va deixar fer-ho.
Així que permetin-me arreglar això.
Ara, deixa tornar a la A la fitxa Inserir aquí i especifiqui
que vull Leitner, Malan i, una fila més, Tov.
I ara, finalment, l'única un que és una mica difícil
és recordar curs instructor.
Anem a inserir, ara que Per descomptat ID1 és instructor ID1
així que això és CS1 i Henry.
ID2 Curs és instructor ID2 que és CS50 i Malan.
I després, els últims els que tenim és preocupar per descomptat ID3
que és CS51, s'ensenya
per descomptat instructor 1, que és Henry.
I tres, com també ensenya per 3, que és Tov.
Així que espero que ara hem recreat aquesta -
maleïda sigui, jo vaig fer el mateix.
L'instructor del curs necessitats d'increment automàtic.
Està bé.
Vaig a fer això més ràpid aquesta vegada, curs 1, curs 1, 2, 2.
I ara, finalment, fem CS51 que té curs ID3 i Henry.
I per descomptat ID3 i Jesse.
Això es veu bé.
D'acord. Així que ara, tornem a la finestra de terminal.
Així que si jo descric cursos ja veurem això.
Si vull veure els cursos que puc ara ho fan seleccioneu estrella dels cursos,
punt i coma, i ara veiem aquests valors.
I ara, què més Què vull fer?
Seleccioneu l'estrella dels instructors, això és el que jo esperava,
i seleccioneu l'estrella dels cursos - curs d'instructor de subratllat.
Llavors, com puc unir-me ara aquestes taules?
Així que la bellesa d'haver triat els valors d'ID d'aquesta manera es
que si es pensa en prenent de la taula suposat
i l'instructor taula i després inserir
entre els dos en el seu ment l'instructor del curs
taula pot espècie de línia per totes aquestes columnes ID
perquè ells es fonen en una columna massiva que té tot
de la informació ens importa.
La sintaxi SQL per a aquest no és necessàriament evident,
però anem a veure si podem fer-ho.
Així que seleccioneu l'estrella dels cursos,
i hi ha una forma en què poques com podem fer això.
Vaig a colpejar Introduïu només per tipus de format coses molt bé,
però això és només una fletxa símptoma de l'eina del costat del client,
no té res a veure amb la pròpia SQL.
Així que seleccioneu l'estrella dels cursos.
Vaig ara a unir-se a la taula cursos
a la taula de l'instructor del curs.
Com? En el camp anomenat courses.id suposat igualant
subratllar instructor dot quin és el nom de
del camp corresponent aquí que vull una parella.
No és ID.
És - el, ho sento?
>> ID del curs.
Bé, deixa allunyar la imatge.
Però vull aprofitar un pas més enllà.
Ara que he fet aquesta taula i aquest.
Ara vull llençar aquest tio endins també.
Així que, permetin-me més unir tot això
en l'instructor de taula en què?
Subratllat Curs Identificació instructor.instructor
igualant instructors.id.
Així que podríem haver escrit aquesta consulta en diverses formes.
L'ordre en que ho vaig fer no és tan important.
Acabo de tipus de vaig fer a la meva ment, d'esquerra a dreta.
Podríem haver fet això en les poques maneres diferents
però si ara tinc la punt i coma i premeu Enter,
Avís torni un nou taula temporal, un conjunt de resultats
per així dir-ho en argot de base de dades.
I què he de en aquesta cosa?
Tinc en ID, un nom, un altre ID, que és una mica confús
per a mi en aquest moment, un identificador de curs,
un identificador instructor, ID, i el nom.
Així, al final del dia tenim les dades en aquests moments.
Puc veure que CS1 s'ensenya by Leitner, CS51 s'ensenya
by Leitner i Tov, i CS50 és impartit per Malan.
Però estic una mica nerviós per aquesta ambigüitat que he creat.
Quina és l'ambigüitat Estic al · ludint a?
Sí?
[Inaudible Observació]
Hi ha tres columnes d'identitat.
Així que en realitat podem solucionar aquest problema i anirem en realitat
ajornar al nostre marc en última instància, perquè ens ajudi amb això,
però resulta que hi ha una paraula clau en SQL anomenada S,
on es pot especificar una àlies, un nou nom per a un camp
de manera que puguem evitar això ambigüitat del tot.
Però es va adonar que si no ho fem tractar d'alguna manera com amb
aquesta paraula clau o un marc,
hi ha potencialment aquest ambigüitat Intentar
per accedir al camp ID perquè és evident que n'hi ha
amb noms duplicats allà.
Així que aquesta és una combinació i crec a l'ull de la seva ment la millor manera
pensar en el que realment és prendre les dues taules,
alinear al manera que vostè desitja.
I aquest és un denominat combinació interna en el sentit
que estem combinant els quadres aquí.
Hi ha altres tipus de s'uneix que podríem trobar
amb el temps, com les combinacions externes,
però en la seva major part aquesta és probablement el més comú
per a la reconstrucció de les dades.
El que hem fet ara és en general, el que s'anomena
la normalització de les dades, de manera que no hi ha duplicació en qualsevol lloc
a les taules.
I a la duplicació, ho faria han fet que la primera aproximació.
Si haguéssim esmentat Leitner i Tov en múltiples llocs
a la base de dades, no és en general, la millor decisió
especialment si el seu nom pot canviar les hores extraordinàries o en el cas
del matrimoni, el nom de soltera força canviar-se a si mateixa el que desitja és una
lloc canònic per a alguns valor de les dades com un nom.
Està bé.
Així que, per recapitular, hem tingut un algunes decisions de disseny per fer
i els més importants probablement reduït a alguns
d'aquestes opcions d'índexs.
Però permetin-me assenyalar una cosa així.
Si torno a anar a phpMyAdmin,
una característica que no podria haver trobat abans és
el següent.
Si vaig al curs d'instructor, Ja vaig especificar que alguns
d'aquestes coses tenen índexs.
Però deixa que me'n vagi a l'estructura pestanya del curs d'instructor.
Permetin-me Faci click sobre els índexs i observeu el següent.
Heus aquí especificat que hi ha una clau primària
a la columna anomenada ID.
Aquest és una mica complicat forma d'especificar la cardinalitat
i així successivament com una referència a la mida del camp en bytes.
Però ara també tinc una altra camp, ID descomptat, que és -
ID descomptat que es fa per avançat i únic, a D'acord.
Ho vaig fer una a avançar per nosaltres.
Així que, per què és això - Deixeu-me caure això pel bé de la discussió.
Oh, ja saps el que vaig fer?
D'acord. Així, abans, un dels perills de la utilització d'una eina d'interfície gràfica d'usuari
així, quan érem La creació d'aquesta taula d'unió,
la taula instructor del curs, Recordo que he especificat
que vull un índex en aquest camp
i un índex en aquesta altre camp.
L'efecte secundari de comprovació tant d'aquestes caixes
a la mateixa pantalla és que phpMyAdmin deduir de l'anterior,
que jo vull no 02:00 índexs separats,
que vull un índex d'unir-se als que és en general només és útil
o la més útil quan estàs buscant en un camp no
però aquests dos camps.
I és per això que vam tenir ells conjuguen allà
així que em vaig deixar caure perquè això no era el que pretenia.
Més aviat, em vaig tornar a fer això aquí.
Vaig a anar a la ID de golf
i baix més Estic dirà afegir índex.
I vaig a passar per sota de ID instructor i dir afegir índex.
I ara, si fem clic aquí AVÍS tenim tres índexs,
un principal i com jo previst per a cada un
d'aquestes claus externes.
I jo en dic l'estranger, ja ID del curs En aquest mapes de taula
a quin camp, només per estar esborrar, en una altra taula.
La clau primària anomenada ID, a la taula anomenada cursos,
i el mateix tracte per a l'altre.
Però ara, és una interessant enganyar i realment tècnica.
Acabo d'anar per davant i em va deixar fer-ho una mica més a poc a poc.
A la mateixa pantalla, l'avís diu Vista de relacions aquí.
Faig clic a això i ara noto jo arribar a fer unes quantes limitacions.
Així, una de les parts superiors també
de no només usant conceptualment claus externes i altres taules
com acabem de és que mitjançant la definició d'un índex
en ells es pot tenir la base de dades d'ajuda que encara més
assegurar la integritat d'aquest camp.
En concret, ara puc especificar a través d'aquesta caiguda
fins que el camp de golf ID
en aquesta taula realitat mapes a courses.id.
De la mateixa manera, subratllat instructor ID assignada a instructors.id.
Ara, per què és això útil?
Bé, fixa't, a la dreta costat del que sembla ara.
Ara puc ensenyar el base de dades que si Henry
per exemple, es jubila mai i la seva fila desapareix
de la taula de l'instructor sent del tot d'aquesta manera
eliminat, el que pugui a través d'aquest cascada enfocament assegurar
que qualsevol dels cursos que imparteix són ja no s'associa amb ell.
Puc ensenyar a la base de dades per eliminar les files
en aquesta crida taula d'unió automàticament si Henry o si un
dels seus cursos desapareix.
Ara, per què és convincent?
Sí?
[Inaudible Observació]
Només has de fer una vegada i llarg termini, no?
És molt fàcil si una mena de les persones van i vénen, vénen els cursos
i vagi, la seva base de dades podria simplement posar-se ple de cursos
i amb els professors que no són ja rellevant per al conjunt de dades.
I els seus dades comença a convertir molt desordenat i brut i ranci,
i aquí podem classificar
de complir alguns aquestes limitacions.
Sí?
[Inaudible Observació]
Se sap per mitjà d'això.
Aquesta és la pantalla on estem especificant un enllaç
entre clau externa i la clau primària.
Així que tota la nomenclatura convencions em vaig referir
anteriorment són només convencions.
No hi ha significat inherent.
Aquesta és la pantalla que només és útil
després que ha especificat els índexs de cada un d'aquests camps com ho vam fer.
I per a aquest desplegable tenim algunes coses, per exemple
si un curs s'elimina puguis en realitat prevenir que la supressió
succeeixi si hi ha és una fila d'aquesta taula
amb només dir, Restringir.
En altres paraules Henry no poden retirar
fins que ho desacoplamos de CS51 i CS1.
Així que això és una bona cosa.
Però podria desencadenar errors en el codi
si vostè no anticipa que, o podem tenir una cascada,
una cascada similar a agradaria fulls d'estil en cascada
i la cascada vol dir que si una cascada -
si Henry es retira de manera - per ser eliminat
també ho farà la seva fila aquí s'eliminen.
Sense acció no significa res o nul és una espècie d'utilitat si tipus
de voler algun registre històric d'Henry havent ensenyat CS51,
però el que desitja és que el camp de ser nul de manera que les files hi
però no és per més temps associat amb ell.
Així que aquests són molt poderosos tècniques que pugui
haureu d'usar fins i tot encara en l'interès particular
de salvar de tu mateix.
Així que permetin-me fer esment d'un parell de detalls finals aquí,
ingredients amb què que podria ser útil
ja que tenim pensat per al disseny de base de dades.
Vostè també té l'elecció sobre el motor de base de dades
que s'utilitza en el codi.
Si està familiaritzat de CS161 vostè pot ser -
o fins i tot 61, és possible que en general estar familiaritzats amb els sistemes de fitxers.
I hi ha coses com, NTFS i HFS +
i X2FS4 [fonètic] i 3 i així successivament.
Hi ha diferents maneres d'emmagatzemar dades a l'escriptori.
De la mateixa manera hi ha diferents formes d'emmagatzematge de dades
en una base de dades per defecte almenys en l'aparell
amb l'última versió de MySQL.
Hem estat utilitzant la motor de base de dades anomenada, Nodb,
que suporta una algunes característiques agradables.
Però una altra comú és també anomenat MyISAM i un altre
que es poden utilitzar és la memòria, el que significa que no posi res
en el disc, només segueix coses a la memòria.
En la seva major part, probablement no sortirà malament acaba de començar
amb Nodb, però per a qualsevol projecte que tendeixen a involucrar les altes taxes de
d'inserció per exemple, com un munt de registre ràpid,
centenars de coses per segon o milers de coses.
Cada vegada que tens un gran quantitat de coses que estan passant
en a la base de dades llavors aquest tipus
les decisions a nivell de la menor començar a involucrar.
La funció de text complet per exemple només funciona en MyISAM
de manera que té una implicació.
Però vostè pot recordar això, anem a almenys motivar per què ens importa
sobre Nodb en particular.
A les condicions de carrera generalment es refereix a què?
Molt bé, aquest és un al · lusió a un exemple una mica de
que poden haver escoltat en any passat si 161 o 50
on vostè té un company de quart, tant de vostès els agrada realment la llet,
un de vosaltres arribi a casa primer s'obre la nevera no hi ha llet,
tancar el passeig a través de nevera carrers a CVS i obtenir
a la fila per comprar una mica de llet.
Mentrestant, el seu company de quart torna aquí.
També li agrada la llet.
Obriu la nevera i s'adona de res de llet.
Aquí ella es dirigeix ​​a la emmagatzemar, potser l'altre CVS.
Avanç ràpid d'un parell de minuts més tard tornes i ara tots dos
que vostè ha comprat llet.
Un d'ells està ara va fer malbé perquè no és així
com la llet que molt i això és un problema, oi?
A causa que els dos inspeccionats l'estat d'alguna variable
i va prendre una decisió basada en ell tot i que l'estat
d'aquesta variable era essencialment en el procés de canviar,
tot sigui lentament sobre el quantitat de temps que triga
per anar i tornar del CVS.
Llavors, què és una mena d'estúpid reals món solució a aquest problema?
Deixa una nota, oi?
Es va passar l'última vegada.
Sempre deixi una nota o un cadenat a la cosa, literalment.
I dic cadenat, perquè si vostè pren o prendre CS161,
de bloqueig és un element fonamental idea en aquesta classe de món.
Així que poden sorgir condicions de carrera també en el món de base de dades
i es pot recordar el millor de CS50 finançar si es pren 50,
el codi que realment vam vostès en l'especificació
en el moment perquè la seva l'operació es diu així atòmica.
Si li agradaria, en aquest cas, compri una acció de les accions
i aquesta població té alguns símbol particular.
Li vam dir que utilitzi un codi com això, perquè a través d'aquest
en l'actualització de clau duplicada sintaxi, que es construeix
en MySQL que està efectivament fent bé en inserció
o en l'actualització després de fent una selecció, per veure
si una acció que ja hi és.
En altres paraules, l'anàleg en el món de la compra d'una acció
de llet i la nevera podria ser, primer,
abans de comprar una participació en Google és possible que voleu seleccionar
de la base de dades de tota la accions de Google que David posseeix
per veure si és propietari de zero o més.
Una vegada que vegi si és propietari zero o més s'ha
a continuació, feu el següent.
Vostè ha de fer una inserció
si pròpia causa zero " no hi ha fila per David, però,
o que ha de fer una actualització si almenys en la teoria de que vols
tenir una fila per cada usuari.
El problema és seleccionar aquest nombre d'accions
i a continuació, l'actualització o inserció podria ser interromput
per una altra persona en un altre terminal d'ordinador tractant de comprar
o vendre part de David de accions de les poblacions ja sigui
per bons propòsits o ordenar de propòsits maliciosos.
És com anar a la botiga quan el seu company de pis torna
i comprova l'estat de la variable.
Així que aquesta sintaxi en el moment que era una espècie d'adequada
per CS50, que evita problema per complet.
I només fa tot això màgia de bloqueig per a vostè,
però ara amb aquest tipus dels projectes per a aquest curs
que molt probablement serà involucrar els conjunts de dades més complexos,
no es pot aconseguir sempre aquesta atomicitat.
Tot succeeix alhora o mai
sense interrupció amb tanta elegància.
I així MySQL, un altre motor de base de dades,
coses de suport anomenats bloquejos,
pel que es pot dir d'aquest bloqueig taula de manera que només un tractament
i en general, només un usuari pot toc en qualsevol punt en el temps
per llegir o escriure i llavors vostè pot desbloquejar.
Aquest és un exemple d'un de les pròpies referències de MySQL,
on si tens com un banc compte que vostè està tractant de
pot descomptar diners de i després afegir diners a.
És possible que vulgueu assegurar-se que tant
d'aquelles coses que passen junts
pel que no hi ha errors matemàtics
i no hi ha pèrdues d'un diners, d'alguna manera.
El problema amb els panys encara que en una base de dades és
que això significa, generalment tota la taula està bloquejada,
el que significa que si vostè té un centenar de persones que tracten
fer negocis amb el seu banc en línia en la mateixa quantitat
de temps de només un dels ells poden anar alhora.
La qual cosa és estúpid, especialment en els servidors d'avui dia
que té vuit plats, 16 Per descomptat, tenir una enorme quantitat
de la memòria, no hi ha raó per serialitzar tots
de les seves transaccions si els els clients només es va
per interactuar amb les seves pròpies files.
Així Nodb li permet fer les coses més intel · ligents
i això serà generalment l'enfocament que vostè prengui en el codi,
com s'utilitza una cosa anomenat la transacció.
I ho fa en general en el codi PHP,
Codi Ruby, Python, el que sigui.
Però el codi SQL que és utilitzat en última instància, és la següent,
normalment.
Inicieu la transacció, llavors especificar dos o més consultes
que desitja executar completament
sense interrupció o no en absolut.
Fins i tot pot haver-hi alguna Seleccionar els enunciats en
o algunes eliminacions o actualitzacions.
Però el millor és que el base de dades serà prou intel · ligent
per assegurar-se que només es bloquejar les files en realitat són
involucrats en aquesta actualització o selecciona o eliminacions.
Així que si tens milers de files i només s'està tocant tres
d'ells, només que subconjunt de la taula es bloquejarà
el que significa que els altres 99 els clients poden tocar les seves files
sense ser serialitzat i frenat per tu.
Mentrestant, aquest és el més bonic aspecte a les transaccions.
Són les operacions en una sentir com 161 en un sistema d'arxius,
són transaccional
el que significa que vostè pot rodar de nou, pot desfer.
Això és com la comanda o controlar F de bases de dades.
Si descobreix part camí a través de tot
de l'operació de dades diferents, disparar, alguna cosa va malament.
Vostè, literalment, executa un diferent rotllo consulta SQL de nou
i tots aquests tendència - tot de les declaracions que ha executat
després d'haver dit inici desaparèixer transacció
com si mai va passar,
que és un increïblement una cosa molt poderós.
I aquests són els tipus de coses certament en 50 classifiquem
d'escombrar sota la catifa i que només una mica d'assumir
que tot anirà bé.
Però una vegada que comenci pensar en projectes reals
i els usuaris reals i el integritat de la base de dades,
aquests són els tipus de les decisions de disseny
que seran importants.