aliassen

Kolomnamen wijzigen

We moeten ook omgaan met de kolomnamen. Anders herhalen we de namen naam en id, maar ze bevatten verschillende gegevens. Aan de andere kant is er de eerste id-kolom en de employee_id-kolom, die dezelfde gegevens bevatten.

Laten we een query schrijven, waar alleen de benodigde kolommen zijn, en ook de kolommen hernoemen met dezelfde namen:

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

En het resultaat van deze vraag:

Geweldig, het probleem met onbegrijpelijke kolomnamen is succesvol opgelost. De query is een beetje lang geworden, maar alles is duidelijk in de resulterende tabel. En geen extra kolommen.

Tabel aliassen

Soms zijn tabelnamen te lang en nemen ze veel ruimte in beslag in de query. Daarom boden de makers van SQL, om de leesbaarheid te verbeteren, zoals in het geval van kolommen, de mogelijkheid om tabelaliassen op te geven.

De algemene vorm van aliassen (tabelaliassen) is als volgt:

FROM table1 alias1, table2 alias2

Laten we onze vorige query herschrijven met korte aliassen:

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

De leesbaarheid is iets afgenomen, maar dit komt doordat de namen van de tabellen aanvankelijk eenvoudig en duidelijk waren. Het zou net zo goed zo kunnen zijn:

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 

En in dit geval zijn aliassen al handig, toch? ;)

hoofdsleutel

En nog een belangrijke informatie over tabellen. Weet je nog dat we een kolom employee_id in de taaktabel hadden? Hiermee verwezen we naar de werknemer-ID uit de werknemerstabel.

Als we van de ene tabel naar de rijen van een andere tabel willen verwijzen, moet de tabel waarnaar wordt verwezen een kolom met een ID hebben, ook wel de primaire sleutel genoemd - PRIMARY KEY .

Meestal is dit een speciaal toegevoegde kolom waarvan het waardetype int is . Bij het toevoegen van records aan een tabel stelt SQL automatisch de waarde van deze kolom in.

Dan zijn er veel dingen gekoppeld aan deze sleutels:

• verschillende tabellen aan elkaar koppelen;
• snel zoeken en filteren op id;
• gegevensintegriteit in de database (geen verwijzingen naar niet-bestaande id);
• gegevens verwijderen waar niemand naar verwijst;
• en vele vele anderen.

Overigens zijn er situaties waarin een tabel een zogenaamde natuurlijke sleutel heeft . Dit is wanneer er een kolom is waarvan de inhoud uniciteit impliceert. We hebben bijvoorbeeld besloten om aan de werknemerstabel toe te voegen:

• De volgorde van aankomst in het bedrijf;
• Btw nummer;
• Nummer en serie van het paspoort.

Soms gebruiken databaseontwerpers een natuurlijke sleutel als primaire sleutel, maar meestal worden ze apart gebruikt. Records kunnen immers worden verwijderd, gewijzigd en dergelijke.

Ik neem aan dat je verhalen op internet leest als gerechtsdeurwaarders schulden van zijn volledige naamgenoot aan een persoon ophangen? Dit heeft alleen te maken met het concept van een unieke sleutel. Voor banken en gerechtsdeurwaarders is het erg handig om een ​​persoon op volledige naam en geboortejaar te zoeken. En in 99% van de gevallen is dit voldoende om een ​​persoon te identificeren.

Maar de overige <1% zijn volledige naamgenoten, met hetzelfde geboortejaar. In het leven van ieder van ons zijn er waarschijnlijk niet zulke mensen, maar op nationale schaal wel. Over het algemeen geldt dat als je software schrijft of een database ontwerpt, het handig is om te weten dat dit ook het geval kan zijn.