Dela upp data i relaterade tabeller

Hittills har vi bara arbetat med en tabell i taget och sett vilka intressanta data vi kan SELECTa ut ur den tabellen. Men i verkligheten, har vi för det mesta vår data fördelade över flera tabeller, och de tabellerna är "relaterade" till varandra på något sätt.

Låt oss t.ex. säga att vi har en tabell för att logga hur bra eleverna får på sina prov och vi inkluderar e-postmeddelanden om vi behöver skicka e-post till föräldrar om vikande betyg:

Vi kan också ha en tabell för att logga vilka böcker varje elev läser:

Vi kan också ha en tabell bara för detaljerad studentinformation:

Vad tycker du om de här tabellerna? Skulle du vilja ändra dem på något sätt?

Det finns en viktig sak att förstå med dessa tabeller: de beskriver relationsdata - Alltså, de beskriver data som är relaterade till varandra. Var och en av dessa tabeller beskriver data som är relaterade till en viss student, och många av tabellerna replikerar samma data. När samma data replikeras över flera tabeller kan det få intressanta konsekvenser.

Till exempel, om en elevs e-post ändras? Vilka tabeller skulle vi behöva ändra i?

Vi skulle behöva ändra studentinformationstabellen, men eftersom vi också inkluderade uppgifterna i betygstabellen(grades table) måste vi också hitta varje rad om den eleven och ändra e-posten där också.

Det är ofta att föredra att en viss kolumn med data bara lagras på en enda plats, så det finns färre platser att uppdatera och mindre risk att ha olika data på olika ställen. Om vi ​​gör det måste vi se till att vi har ett sätt att relatera/koppla data över tabellerna, vilket vi kommer att återkomma till senare.

Vi säger att vi bestämmer oss för att ta bort e-post från betygstabellen, eftersom vi inser att det är överflödigt med e-postmeddelandet i studentinformationstabellen. Det här är vad vi då skulle ha:

Hur kan vi lista ut e-post för varje elev? Vi skulle kunna hitta raden i studentinformationstabellen, matchande med namn. Vad händer om 2 elever hade samma namn? (Visste du att på Bali har varje person bara ett av fyra möjliga förnamn?) Vi kan inte lita på namn för att leta upp en student, och vi borde aldrig lita på något som namn för att identifiera någonting unikt i en tabell.

Så det bästa är att ta bort student_name och ersätta det med student_id, eftersom det är en garanterad unik identifierare:

Vi skulle göra samma förändring till vår boktabell, med hjälp av student_id istället för student_name:

Lägg märke till hur vi har titeln och författaren upprepade två gånger för Jabberwocky? Det är en ytterligare varningsflagga att vi kan dela upp vår tabell i flera relaterade tabeller, så att vi inte behöver uppdatera flera platser om något ändras om en bok.

Vi kan ha en tabell bara om böcker:

Och så blir vår student_books tabell:

Jag vet att den här tabellen inte är ens i närheten av lika läsbar som den gamla tabellen som hade all information fylld i varje rad. Men tabellerna är ofta inte avsedda att vara läsliga för människor - de är utformade för att vara det bästa sättet att lagra data med minsta möjliga underhållsbehov, minst risk för buggar (och även prestanda hoppas man). I många fall kan det vara bäst att dela upp information i flera relaterade tabeller, så att det finns mindre överflödig data och färre platser att uppdatera.

Det är viktigt att förstå hur man använder SQL för att hantera data som har delats upp i flera relaterade tabeller, och sätta ihop datan igen från olika tabeller när man behöver det. Vi gör det med ett koncept som heter "join" s och det är det jag ska visa dig nu.