Sütun adlarını değiştirme

Sütun adlarıyla da ilgilenmemiz gerekiyor. Aksi takdirde, ad ve kimlik adlarını tekrar ederiz, ancak bunlar farklı veriler içerir. Öte yandan, aynı verileri içeren ilk id sütunu ve çalışan_id sütunu vardır.

Sadece gerekli sütunların olacağı bir sorgu yazalım ve sütunları aynı adlarla yeniden adlandıralım:

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

Ve bu sorgunun sonucu:

görev_kimliği görev_desc son teslim tarihi çalışan kimliği emp_adı emp_occupation
1 Ön uçtaki bir hatayı düzeltin 2022-06-01 1 İvanov İvan Programcı
2 Arka uçtaki bir hatayı düzeltin 2022-06-15 2 Petrov Petr Programcı
7 Hayatın tadını çıkar (HÜKÜMSÜZ) 4 Rabinovich Moisha Müdür
3 kahve satın al 2022-07-01 5 Kirienko Anastasia Ofis Yöneticisi
4 kahve satın al 2022-08-01 5 Kirienko Anastasia Ofis Yöneticisi
5 kahve satın al 2022-09-01 5 Kirienko Anastasia Ofis Yöneticisi
8 Hayatın tadını çıkar (HÜKÜMSÜZ) 6 Vaska kedi

Harika, anlaşılmaz sütun adlarıyla ilgili sorun başarıyla çözüldü. Sorgu biraz uzadı, ancak ortaya çıkan tabloda her şey açık. Ve fazladan sütun yok.

Tablo takma adları

Bazen tablo adları çok uzundur ve sorguda çok yer kaplar. Bu nedenle, SQL'in yaratıcıları, sütunlarda olduğu gibi okunabilirliği artırmak için, tablo takma adlarını belirleme olanağı sundu.

Takma adların (tablo takma adları) genel biçimi aşağıdaki gibidir:

FROM table1 alias1, table2 alias2

Önceki sorgumuzu kısa takma adlarla yeniden yazalım:

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

Okunabilirlik biraz azaldı, ancak bunun nedeni tabloların adlarının başlangıçta basit ve net olmasıydı. Şu şekilde de olabilir:

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 

Ve bu durumda, takma adlar zaten yararlıdır, değil mi? ;)

birincil anahtar

Ve tablolar hakkında bir önemli bilgi daha. Görev tablosunda bir çalışan_kimliği sütunumuz olduğunu hatırlıyor musunuz? Bununla, çalışan tablosundan çalışan kimliğine başvurduk.

Bir tablodan başka bir tablonun satırlarına başvurmak istiyorsak, başvurulan tablonun, birincil anahtar - PRIMARY KEY olarak da adlandırılan kimliği olan bir sütunu olmalıdır .

Çoğu zaman bu, değer türü int olan özel olarak eklenen bir sütundur . Bir tabloya kayıt eklerken, SQL bu sütunun değerini otomatik olarak ayarlar.

O zaman bu anahtarlara pek çok şey bağlanır:

  • farklı tabloları birbirine bağlamak;
  • kimliğe göre hızlı arama ve filtreleme;
  • veritabanındaki veri bütünlüğü (var olmayan kimliğe referans yok);
  • kimsenin başvurmadığı verileri silmek;
  • ve diğerleri.

Bu arada, bir tablonun sözde doğal anahtara sahip olduğu durumlar vardır . Bu, içeriği benzersizliği ima eden bir sütun olduğu zamandır. Örneğin, çalışan tablosuna şunları eklemeye karar verdik:

  • Şirkete geliş sırası;
  • Vergi numarası;
  • Pasaport numarası ve serisi.

Bazen veritabanı tasarımcıları birincil anahtar olarak doğal bir anahtar kullanır, ancak çoğu zaman ayrı olarak kullanılırlar. Sonuçta kayıtlar silinebilir, değiştirilebilir ve benzeri şeyler yapılabilir.

İcra memurlarının bir kişiye tam adaşının borçlarını astığına dair internette hikayeler okuduğunuzu varsayıyorum? Bu sadece benzersiz bir anahtar kavramıyla ilgilidir. Bankaların ve icra memurlarının bir kişiyi tam adı ve doğum yılına göre araması çok uygundur. Ve vakaların %99'unda bu, bir kişiyi teşhis etmek için yeterlidir.

Ancak kalan <%1, aynı doğum yılına sahip tam adaşlardır. Her birimizin hayatında büyük olasılıkla böyle insanlar yoktur, ancak ulusal ölçekte vardır. Genel olarak, yazılım yazıyorsanız veya bir veritabanı tasarlıyorsanız, bunun da böyle olabileceğini bilmenizde fayda var.