Ciao, e benvenuti alla nostra lezione su SQL.
Quindi questa è un'
introduzione molto, molto breve a SQL.
Adoro SQL.
L'
altro giorno parlavo con uno studente e mi dissero
: «SQL è la mia lingua preferita».
E ho detto, «Devo essere d'accordo sul fatto che
SQL è anche la mia lingua preferita».
Poiché SQL è così bello,
non hai nemmeno bisogno di scrivere loop in SQL,
scriviamo loop in linguaggi come
Python solo perché dobbiamo.
Il problema è che SQL è perfetto,
ma non è il modo in cui potremmo scrivere
qualcosa di complesso come Linux o Python.
Quindi SQL non è proprio il modo in cui pensano i computer,
abbiamo queste cose chiamate motori di database,
e questi motori di database fanno
funzionare le cose davvero, molto bene.
Quindi SQL è un ottimo modo per organizzare i dati,
ma un sacco di lavoro è andato a
mantenere quei dati organizzati e rendendoli semplici.
Quindi è come se ci fosse questa astrazione,
ed è un sacco di lavoro per far funzionare quell'astrazione.
Quindi voglio iniziare con un po'
di storia prima dei database,
e potreste pensare, «Beh, prima
dei database, come potrebbe essere?»
Beh, ai vecchi tempi,
e se guardate vecchi film con computer,
vedete immagini che hanno
queste macchine a nastro
sullo sfondo e girano.
E la filatura della macchina a nastro è il
tipo di manifestazione fisica di un calcolo.
E aveva a che fare con il fatto che ai vecchi tempi,
i computer non avevano abbastanza dati
per memorizzare tutti i loro dati nella memoria o su un disco,
non avevamo nemmeno i dischi nei primi giorni.
All' inizio, i nastri erano ciò che avevamo,
e usavamo una specie di variazione di nastri audio,
e invece di audio,
contenevano dati, zeri e uno.
E così il modo in cui le cose
funzionavano ai vecchi tempi in modo da poter avere un database, per così dire,
era che il database era tutti
i dati registrati su un nastro.
E la cosa chiave di un nastro
è che era una cosa fisica,
e quindi dovevi riavvolgerla,
andare avanti e indietro.
E la maggior parte di voi probabilmente
non ha mai visto una cassetta o un nastro a otto tracce
o una bobina a bobina,
ma è un pezzo di plastica lungo mille piedi,
e per ottenere i dati alla fine,
dovevi farlo girare fino a quando arrivavi.
E quindi non era quello che chiamiamo accesso casuale, il
che significa che in un accesso casuale, che
si tratti di memoria o unità disco,
l'accesso casuale consente di raggiungere
qualsiasi luogo approssimativamente in un determinato lasso di tempo.
Mentre, se sei vicino a qualcosa su un nastro,
puoi arrivarci molto velocemente.
Se sei lontano, devi andare,
e poi aspettare, e poi tornare.
Quindi questo ha portato a uno schema
in cui ogni sera
prendevamo il nastro dai conti di ieri.
Diciamo solo che siamo una banca,
e ci sono persone che arrivano alla finestra,
mettono soldi, tirano fuori soldi.
E poi quello che faremmo e' mettere tutte
le transazioni, a volte su carte fisicamente perforate,
e poi le sistemavamo, giusto?
E diciamo solo che abbiamo 26 account e la persona C
si presenta aggiunge $10 e la persona F
si presenta e sottrae $10, ecc, ecc
E poi quello che avremmo di notte,
avremmo ottenuto questi tutti ordinati,
e c'erano macchine fisiche che
avrebbero effettivamente ordinare questi nel primo di giorni,
e poi avremmo il vecchio equilibrio,
A, B, C, D,
E, F, seduto su un nastro in ordine, ordinati in ordine.
Avremmo iniziato un processo dopo la chiusura della banca,
dove avremmo letto il primo record dal nastro come A,
avremmo letto la prima transazione dalle carte,
e li avremmo confrontati.
E se il nastro fosse
prima della transazione
o inferiore, lo copiavamo, quindi lo copiavamo.
E poi così la B si confrontava con la C,
e B sarebbe stato copiato,
e poi C si sarebbe imbattuto,
e poi ci saremmo resi conto che i dati
C, avremmo dovuto aggiornare i dati C,
e aggiungere $10 al saldo, e poi lo avremmo scritto.
E noterai mentre stiamo scrivendo questo,
stiamo ordinando, è in ordine ordinato.
Poi abbiamo copiato D, non abbiamo nulla per D,
e sarebbe solo essere copiato.
Copiavamo E, non abbiamo niente per E,
e sarebbe stato copiato,
e poi avremmo, oops, dimenticato di mettere F su questa foto,
avremmo F e ne avremmo sottratto 10, e lo avremmo copiato.
E poi avremmo finito con
il tipo di cose che dovevamo fare quella notte,
e poi quello che avremmo fatto è avere
questi nuovi dati aggiornati che erano
tutti ordinati in ordine di conto.
E poi la notte dopo,
spostavamo il nastro,
il nuovo nastro sarebbe il vecchio nastro,
e lo facevamo più e più volte.
E a volte questi processi funzionavano
per quattro o cinque ore perché i nastri erano lunghi o
dovevano essere più nastri,
e così un sacco di calcolo veniva
fatto dopo che le banche
chiudevano alle cinque, poi arrivava un gruppo di persone, li chiamavamo operatori, monta questi nastri ed esegui
questi lavori e basta stare lì a guardare
questi nastri girare mentre i dati venivano
copiati da uno all'altro.
Quindi si', e' piuttosto figo.
Fortunatamente, non e' piu' cosi' che facciamo.
La cosa che ha fatto in modo che non dobbiamo
farlo è l'invenzione delle unità disco.
E le unità disco sono supporti magnetici,
proprio come le unità a nastro,
ma la differenza era che erano
su questi vassoi rotanti.
Quindi quello che si poteva fare è che i dati
erano in una serie di cerchi concentrici su questi vassoi,
e poi si aveva una testa
che poteva muoversi rapidamente dentro e fuori.
E così la velocità con cui si poteva accedere ai dati era
una combinazione con la velocità alla quale
la testa poteva spostarsi su un determinato cilindro,
e si doveva aspettare che i dati arrivassero.
E così a volte avresti 5.400 giri al minuto.
Ciò significa che 5.400,
5.000 volte al minuto,
che è 100 volte al secondo.
Si aspetterebbe un centesimo di secondo.
E quindi questo è molto meglio che aspettare un minuto e mezzo,
due minuti, anche 10 minuti per far girare un nastro.
Quindi il problema era:
«Ok,
ora che abbiamo questa meravigliosa tecnologia,
possiamo archiviare tutti i nostri dati notturni
su un disco perché è abbastanza spazio,
come costruiamo la
tecnologia per farne un buon uso?»
E un sacco di ricerche,
un sacco di informatica,
un sacco di ricerche sui fornitori sono andate a
capire come usare al meglio questa nuova cosa del disco.
Ricordo di aver parlato con la gente come,
perché usavamo un floppy disk,
che erano molto più lenti,
quindi non sono andati a 5.400.
Quindi potrebbe volerci un quarto di secondo per muovere
la testa e potrebbe volerci
quasi un secondo per girarla,
che era ancora molto più veloce di 10 minuti, giusto?
Quindi è come circa un secondo per arrivare a
qualsiasi punto del floppy disk.
E costruiremmo approcci per la memorizzazione dei dati,
e iniziavamo con questa cosa fisica
e tu la sentivi grugnire,
muoversi,
grugnire e muoversi, e poi avresti trovato un modo migliore
per memorizzare i dati,
e poi grugnito e spostato meno,
e la tua cosa sarebbe Vai più veloce.
Quindi era come una cosa di ricerca.
Erano bei vecchi tempi in cui i computer facevano dei rumori,
e potevi cambiare il tuo codice all'interno dei computer.
E la prima cosa, ovviamente, che abbiamo fatto è stata solo
prendere quegli aggiornamenti master sequenziali e metterli su,
ma quello si è rivelato non essere il migliore.
E questa era una specie di ricerca è,
non solo come possiamo fare quello che
facevamo su dati che non potevano
essere accessibili in modo casuale, e invece,
diciamo cerchiamo di approfittarne.
E così un sacco di ricerche, un sacco di fornitori,
c'era un sacco di software molto costoso
che la gente comprava per dire:
«Guarda, sei una banca,
e vuoi davvero sapere come funziona.»
E così quello che è successo è stato negli anni '60 e '70,
i fornitori di computer stavano combattendo,
e avrebbero escogitato una tecnica,
che rispetto alla nostra attuale tecnica
di database, era banalmente semplice, ma ci volle molto lavoro all'epoca,
e combattevano con tutti gli altri fornitori di computer,
e direbbero, «Il nostro
meccanismo sequenziale indice è migliore.»
E Vendor 2 direbbe:
«Il nostro approccio alla rete è migliore».
E poi si sedevano, e
lottavano l'uno con l'altro,
e poi i poveri clienti dicevano
: «Non so nemmeno di cosa stai parlando».
E poi compravano
la roba dal venditore che li
portava a golf o per
il miglior pranzo o li portava in Florida.
E poi si sarebbero adattati
a qualsiasi cosa avesse fatto quel venditore.
E quindi era davvero un po' spaventoso perché ci stavamo
trasferendo in un posto dove eri rinchiuso in un venditore,
e poi una volta rinchiuso in
un venditore, sei in cattive condizioni.
E così il governo americano,
in particolare, aveva un sacco
di soldi e stava comprando tonnellate di computer,
sia per la normale elaborazione dei dati che per
cose strategiche come roba militare,
e così stavano comprando tonnellate di computer e
sapevano che questi fornitori,
se arrivassero al punto dove
li hanno bloccati in un unico fornitore,
che il fornitore sarebbe solo in grado di dettare il prezzo.
E così il governo federale, attraverso il NIST,
l'Istituto Nazionale di Standard e Tecnologia,
ha deciso che i database avevano bisogno di uno standard.
Avevano bisogno di un modo in modo che
potessimo parlare con qualsiasi database di qualsiasi fornitore usando
la stessa tecnica e non dover fare un fornitore,
e poi se hai cambiato fornitore,
dovevi riscrivere completamente il tuo software.
Quindi NIST non ha specificato come questa astrazione
, questo standard, avrebbe funzionato.
Hanno appena portato i fornitori e hanno detto,
«Smetteremo di usare
il tuo software se non trovi uno standard».
Ed era un momento perfetto perché anche se
i venditori pensavano che tutto fosse perfetto e meraviglioso,
c'era un sacco di vantaggi.
E in particolare, c'era
questo concetto di database relazionali,
che allora era più
una teoria matematica di un modo migliore per memorizzare
e recuperare i dati rispetto a
una tecnologia disponibile praticamente implementata.
E così SQL, e questa è Liz Fong,
che sono andato e ho fatto un'intervista al NIST,
lei parla dei primi giorni,
è una grande intervista,
i primi giorni di come questo standard SQL ha
davvero molto senso e davvero risolto
il settore e ha fatto funzionare l'industria davvero bene.
E vi consiglio di dare un'occhiata a
questo video solo in modo da poter tipo di vedere.
Ora, quello che SQL fondamentalmente ha detto
è che non preoccupatevi così tanto di dove quei dati sono effettivamente sul disco, perché i
precedenti approcci al database se
noi programmatori sapevamo che c'
erano cilindri
e posizioni, e avremmo posto le cose in certi modi,
e avremmo fare indici
e noi guarderemmo gli indici noi stessi,
ogni tipo di cose diverse,
o avremmo letto in un posto sul disco e che
avrebbe un indirizzo del posto successivo che
dovremmo leggere sul disco.
E hanno detto: «Sai una cosa,
non preoccupatevi così tanto
della struttura di archiviazione fisica sulla scrivania, ma, invece,
cerchiamo
di trovare un linguaggio con cui possiamo esprimere ciò che
vogliamo leggere, scrivere, aggiornare
ed eliminare sul disco in un linguaggio molto semplice,
e poi può costruire un pezzo di software
che potrebbe esserci molti formati di disco al di sotto di esso.
E poi potremmo usare questo linguaggio e tu potresti
comprare il Vendor A e usare
questo linguaggio e il Vendor B e usare questo linguaggio,
e poi potresti anche paragonarlo e dire,
«Ecco un sacco di cose in questa lingua.
Quale fornitore può eseguire questo più velocemente?»
E così il NIST aveva anche una serie di benchmark,
TPC erano alcuni dei benchmark.
E quindi quello che hanno fatto è che fondamentalmente hanno
fatto in modo che questo era come un linguaggio bello e semplice,
ed è quello che chiamiamo SQL.
Penso che a un certo punto si chiamasse
Simple Query Language,
ed è il linguaggio che usiamo per parlare con i database.
E la cosa interessante è che SQL ci ha permesso di
fare davvero negli anni '60 e '70 quando è uscito per
la prima volta, era parlare con i database vecchio stile come database indice,
sequenziali e in stile di rete,
e come questa nuova forma chiamata database relazionali,
che aveva come questo fantastico base matematica,
ma è stato implementato male nella prima volta,
potremmo solo dire, «Oh strano».
Quando le prestazioni dei database relazionali arrivarono
al punto in cui era buono come gli altri database,
allora potevamo semplicemente passare e potevamo parlare lo stesso SQL.
Così ha permesso una straordinaria innovazione in
un periodo di 10 o anche 15 anni,
dove l'astrazione ci ha permesso di migliorare i database in
modo meraviglioso senza
dover davvero cambiare il modo in cui noi come programmatori li abbiamo usati.
Dang fantastico, saro' onesto.
E così ho parlato di questa idea di database
relazionali e database relazionali, e
ammetto che quando ho visto per la prima volta
i database relazionali nei primi anni '80, sono tipo,
è una schifezza, perché di nuovo,
ho potuto sentire i floppy disk e sapevo che
stavamo spostando una cosa e Avevo
così tanta consapevolezza di quello che stava succedendo,
e mi piaceva quella consapevolezza.
E i database relazionali come nascondevano
cosa stava succedendo dietro questo livello,
e si è scoperto che ogni volta che lo usavo,
era più lento perché non era ancora intelligente.
E così i database relazionali sono
iniziati come un'idea matematica come
il modo migliore teorico per rappresentare
reti di dati con colonne
, righe, connessioni e join,
e parleremo di tutto ciò alla fine.
Ed era una bella idea e la matematica aveva ragione.
Ci è voluto molto tempo per arrivare al
punto in cui la matematica superiore dei
database relazionali ha funzionato
meglio rispetto ai
sistemi di database della generazione precedente altamente ottimizzati.
Quindi ci sono molti sistemi di database comuni
che incontrerai.
Alcuni di loro sono open source,
alcuni di loro sono commerciali.
Postgres e MySQL sono open source.
Postgres è probabilmente il più
complicato e complesso e ricco,
Oracle è un
database intricato, complesso e ricco che è
disponibile per un sacco di soldi,
e Microsoft ha un database chiamato SQL Server.
E tutti questi database che stiamo vedendo si sono evoluti in
un certo senso dopo che le specifiche SQL esistevano,
quindi hanno semplicemente costruito SQL.
C' erano database legacy che tipo di imparato SQL.
E ci sono un sacco di altri database.
SQLite è ciò che
useremo con questo corso,
ed è super cool, super veloce.
Sul tuo telefono cellulare,
probabilmente hai 40 copie di SQLite,
e nella tua auto, probabilmente hai 40 copie di
SQLite, perché è un vero e proprio piccolo database incorporato.
Non è molto buono per la scala di produzione.
Quando hai 100 utenti che
colpiscono simultaneamente un sito Web,
Postgres, MySQL, Oracle o SQL Server
sono davvero una specie di database multiprocessing online reali.
Ma SQLite è fantastico perché è davvero semplice.
Memorizza tutto in un file,
possiamo spostare il file in giro, ecc
Quindi amo SQLite,
e in questa classe e in questa cosa
parleremo di SQLite.
Ma tutto ciò di cui parliamo
si applica a tutti questi diversi sistemi di database.
Quindi la prima cosa che devi fare quando
lavorerai con il database è che
devi trovare un contratto
tra te e il database su
quale sia la forma delle
colonne, quanto sono larghe le colonne,
che tipo di dati memorizzerai in questo.
E poi informa come
il software del database sta per
strutturare quel database come sul disco.
E parte di quello che stai facendo è che stai
permettendo al software di database, MySQL,
o Postgres, o SQLite, di super-ottimizzare il suo storage.
E' molto piu' intelligente di te.
Qualcosa come Oracle, o MySQL,
o Postgres probabilmente rappresenta un miliardo di dollari,
se non di più, di ricerca e
sviluppo sul modo migliore
per archiviare e recuperare i dati.
E non hai nemmeno bisogno di sapere niente di tutto questo.
Dici solo, guarda, ho intenzione di avere queste colonne, avrà
un 100 caratteri di testo,
poi ho intenzione di avere un numero intero e
un numero in virgola mobile, poi 3.000 caratteri di testo,
e ti preoccupi di tutti quei dettagli.
Ma la chiave è che se dici semplicemente,
«memorizzerò tutto ciò che voglio», allora non può ottimizzare,
e quindi c'è questa cosa in cui devi
stipulare un contratto all'inizio e dire:
«Questo è esattamente il modo in cui stenderò
i dati mentre parlo con il sistema di database.
e poi si può capire come
disporre i dati nel disco reale.»
E così questo è chiamato lo schema o il modello di database,
e la costruzione di un modello di database è di per sé una cosa interessante.
Quindi, se stai costruendo un'applicazione complessa,
hai questi modelli e loro hanno connessioni,
e alla fine parleremo di tutte queste cose.
Ma è fondamentale dire
che questo è un contratto tra te e
il software del database in modo che
il software del database possa
ottimizzare l'archiviazione del database.
Ora, una volta dato lo schema,
è possibile scrivere query che dipendono da tale schema.
Quindi potresti avere una colonna chiamata
email e una colonna chiamata nome,
quindi puoi inserire dati
nel database usando quello schema,
puoi recuperare i dati usando lo schema,
puoi modificare i dati da qualche parte nel profondo del database
e quindi puoi eliminare i dati.
Aspetta un secondo. Wow. Ciao, lì.
Che ci fai laggiù? Oh, dannazione.
Scusa, scusami. Sei una creatura cattiva.
Guarda che roba. Mi chiedevo cosa fosse quel rumore.
Vieni qui. Devo presentarti a tutte queste persone.
Vieni qui.
Non ti stai comportando.
Quindi questa e' Shelby.
Ciao, Shelby. Quindi questa e' Shelby. Questo è il mio cucciolo.
Sto cercando di tenerla fuori dalla
gabbia e lasciarla sedermi per i piedi,
e lei ha dei giocattoli da masticare.
Ciao, Shelby. Lei è Shelby.
Lei sta interrompendo.
Stai interrompendo la mia lezione. Ma sei carina.
Quindi smettila di masticare la penna,
mastica i tuoi giocattoli da masticare che ti ho dato, ok?
Fammi superare questa lezione.
Ok, puoi scendere.
Smettila di masticarlo.
Mi dispiace per l'interruzione del cane.
Stavo solo sentendo dei rumori masticanti e ho pensato,
ho preso tutto, ma poi
c'era una penna sul pavimento,
e così la penna, povera penna incontra il signor Cucciolo.
Oh, beh... Ok, dov'ero?
SQL. CRUD, creare, leggere
, aggiornare ed eliminare i dati.
E quindi il nostro prossimo passo è quello di
fare effettivamente un po 'di SQL e creare un database.
[ MUSIC]