Aliaser

Endre kolonnenavn

Vi må også forholde oss til kolonnenavnene. Ellers gjentar vi navnene navn og id, men de inneholder forskjellige data. På den annen side er det den første id-kolonnen og kolonnen ansatt_id, som inneholder de samme dataene.

La oss skrive en spørring, der det bare vil være de nødvendige kolonnene, og også gi nytt navn til kolonnene med samme navn:

SELECT  
    task.id AS task_id,  
    task.name AS task_desc, 
    task.deadline AS deadline, 
    emploee.id AS emploee_id,  
    emploee.name AS emp_name,  
emploee.occupation AS	
    emp_occupation 
FROM employee, task
WHERE emploee.id = task.emploee_id

Og resultatet av denne spørringen:

Flott, problemet med uforståelige kolonnenavn har blitt løst. Spørringen har blitt litt lang, men alt er klart i den resulterende tabellen. Og ingen ekstra kolonner.

Tabellaliaser

Noen ganger er tabellnavn for lange og tar opp mye plass i spørringen. Derfor tilbød skaperne av SQL, for å forbedre lesbarheten, som i tilfellet med kolonner, muligheten til å spesifisere tabellaliaser.

Den generelle formen for aliaser (tabellaliaser) er som følger:

FROM table1 alias1, table2 alias2

La oss omskrive vår forrige spørring med korte aliaser:

SELECT  
    t.id AS task_id,  
    t.name AS task_desc, 
    t.deadline AS deadline, 
    e.id AS emploee_id,  
    e.name AS emp_name,  
    e.occupation AS emp_occupation 
    FROM employee e, task t 
WHERE e.id = t.emploee_id

Lesbarheten har gått litt ned, men dette skyldes at navnene på tabellene i utgangspunktet var enkle og klare. Det kan like gjerne være slik:

SELECT  
  	task.id AS task_id,  
  	task.name AS task_desc, 
  	task.deadline AS deadline, 
  	emploee.id AS emploee_id,  
  	emploee.name AS emp_name,  
emploee.occupation AS	
  	emp_occupation 
FROM  
  	Microsoft_it_department_employee employee, 
  	Year2022_priority_task task 
WHERE emploee.id = task.emploee_id 

Og i dette tilfellet er aliaser allerede nyttige, ikke sant? ;)

primærnøkkel

Og enda en viktig informasjon om tabeller. Husker du at vi hadde en ansatt_id-kolonne i oppgavetabellen? Med den refererte vi til ansatt-ID fra ansatttabellen.

Hvis vi ønsker å referere fra en tabell til radene i en annen tabell, må den refererte tabellen ha en kolonne med en ID, som også kalles primærnøkkelen - PRIMÆRKØKKEL .

Oftest er dette en spesielt lagt til kolonne hvis verditype er int . Når du legger til poster i en tabell, setter SQL automatisk verdien for denne kolonnen.

Da er mange ting knyttet til disse nøklene:

• koble forskjellige tabeller til hverandre;
• raskt søk og filtrering etter id;
• dataintegritet i databasen (ingen referanser til ikke-eksisterende id);
• sletting av data som ingen refererer til;
• og mange mange andre.

Forresten, det er situasjoner når et bord har en såkalt naturlig nøkkel . Dette er når det er en kolonne hvis innhold antyder unikhet. For eksempel bestemte vi oss for å legge til i ansatttabellen:

• Rekkefølgen på deres ankomst i selskapet;
• Skattenummer;
• Nummer og serie på passet.

Noen ganger bruker databasedesignere en naturlig nøkkel som primærnøkkel, men oftest brukes de separat. Tross alt kan poster slettes, endres og lignende.

Jeg antar at du leser historier på Internett når namsmenn henger gjeld til hans fulle navnebror på en person? Dette er bare relatert til konseptet med en unik nøkkel. Det er veldig praktisk for banker og namsmenn å søke etter en person med fullt navn og fødselsår. Og i 99% av tilfellene er dette nok til å identifisere en person.

Men de resterende <1% er fulle navnebror, med samme fødselsår. I hver enkelt av oss er det mest sannsynlig ingen slike mennesker, men på nasjonalt plan er det det. Generelt, hvis du skriver programvare eller designer en database, er det nyttig å vite at dette også kan være tilfelle.