Álnevek

Oszlopnevek módosítása

Az oszlopnevekkel is foglalkoznunk kell. Ellenkező esetben megismételjük a nevet és az azonosítót, de ezek eltérő adatokat tartalmaznak. Másrészt van az első id oszlop és az alkalmazott_azonosító oszlop, amelyek ugyanazokat az adatokat tartalmazzák.

Írjunk egy lekérdezést, ahol csak a szükséges oszlopok lesznek, és nevezzük át az oszlopokat azonos névvel:

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

És ennek a lekérdezésnek az eredménye:

Remek, az érthetetlen oszlopnevekkel kapcsolatos probléma sikeresen megoldva. Kicsit hosszú lett a lekérdezés, de a kapott táblázatban minden világos. És nincsenek extra oszlopok.

Táblázat álnevek

Néha a táblanevek túl hosszúak, és sok helyet foglalnak el a lekérdezésben. Ezért az SQL megalkotói az olvashatóság javítása érdekében, akárcsak az oszlopok esetében, felajánlották a táblaálnevek megadásának lehetőségét.

Az álnevek (táblázati álnevek) általános formája a következő:

FROM table1 alias1, table2 alias2

Írjuk át korábbi lekérdezésünket rövid álnevekkel:

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

Az olvashatóság némileg csökkent, de ennek az az oka, hogy a táblázatok nevei kezdetben egyszerűek és egyértelműek voltak. Ez akár így is lehet:

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 

És ebben az esetben az álnevek már hasznosak, nem? ;)

elsődleges kulcs

És még egy fontos információ a táblázatokról. Emlékszel, hogy a feladattáblázatban volt egy alkalmazott_azonosító oszlopunk? Ezzel az alkalmazotti táblából hivatkoztunk az alkalmazotti azonosítóra.

Ha egy táblából egy másik tábla soraira akarunk hivatkozni, akkor a hivatkozott táblának rendelkeznie kell egy azonosítóval ellátott oszloppal, amelyet elsődleges kulcsnak is nevezünk - PRIMARY KEY .

Leggyakrabban ez egy speciálisan hozzáadott oszlop, amelynek értéktípusa int . Amikor rekordokat ad hozzá egy táblához, az SQL automatikusan beállítja ennek az oszlopnak az értékét.

Aztán sok minden kötődik ezekhez a kulcsokhoz:

• különböző táblák összekapcsolása egymással;
• gyors keresés és szűrés azonosító alapján;
• adatintegritás az adatbázisban (nincs hivatkozás nem létező azonosítóra);
• olyan adatok törlése, amelyekre senki sem hivatkozik;
• és még sokan mások.

Egyébként vannak olyan helyzetek, amikor egy táblázatnak van egy úgynevezett természetes kulcsa . Ilyenkor van egy oszlop, amelynek tartalma egyediségre utal. Például úgy döntöttünk, hogy hozzáadjuk az alkalmazottak táblázatához:

• A társaságba érkezésük sorrendje;
• Adószám;
• Az útlevél száma és sorozata.

Néha az adatbázis-tervezők természetes kulcsot használnak elsődleges kulcsként, de leggyakrabban külön-külön. Hiszen a rekordokat lehet törölni, módosítani és hasonlókat.

Gondolom, olyan történeteket olvasott az interneten, amikor a végrehajtók ráakasztják a teljes névrokonának tartozását egy személyre? Ez csak az egyedi kulcs fogalmához kapcsolódik. A bankok és a végrehajtók számára nagyon kényelmes, hogy teljes név és születési év alapján keressenek egy személyt. És az esetek 99% -ában ez elegendő egy személy azonosításához.

De a maradék <1% teljes névrokon, azonos születési évvel. Valószínűleg mindegyikünk életében nincsenek ilyen emberek, de országos viszonylatban igen. Általában, ha szoftvert ír, vagy adatbázist tervez, akkor hasznos tudnia, hogy ez is előfordulhat.