Alias

Menukar nama lajur

Kita juga perlu berurusan dengan nama lajur. Jika tidak, kami mengulangi nama dan id nama, tetapi ia mengandungi data yang berbeza. Sebaliknya, terdapat lajur id pertama dan lajur employee_id, yang mengandungi data yang sama.

Mari tulis pertanyaan, di mana terdapat hanya lajur yang diperlukan, dan juga menamakan semula lajur dengan nama yang sama:

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

Dan hasil daripada pertanyaan ini:

Hebat, masalah dengan nama lajur yang tidak dapat difahami telah berjaya diselesaikan. Pertanyaan telah menjadi agak panjang, tetapi semuanya jelas dalam jadual yang terhasil. Dan tiada lajur tambahan.

Alias ​​jadual

Kadangkala nama jadual terlalu panjang dan mengambil banyak ruang dalam pertanyaan. Oleh itu, pencipta SQL, untuk meningkatkan kebolehbacaan, seperti dalam kes lajur, menawarkan keupayaan untuk menentukan alias jadual.

Bentuk umum alias (alias jadual) adalah seperti berikut:

FROM table1 alias1, table2 alias2

Mari tulis semula pertanyaan kami sebelumnya dengan alias pendek:

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

Kebolehbacaan telah berkurangan sedikit, tetapi ini kerana nama jadual pada mulanya ringkas dan jelas. Mungkin juga seperti ini:

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 

Dan dalam kes ini, alias sudah berguna, bukan? ;)

kunci utama

Dan satu lagi maklumat penting tentang jadual. Ingat bahawa kami mempunyai lajur employee_id dalam jadual tugas? Dengan itu, kami merujuk ID pekerja daripada jadual pekerja.

Jika kita ingin merujuk dari satu jadual ke baris jadual lain, maka jadual yang dirujuk mesti mempunyai lajur dengan ID, yang juga dipanggil kunci utama - PRIMARY KEY .

Selalunya, ini ialah lajur yang ditambah khas yang jenis nilainya ialah int . Apabila menambah rekod pada jadual, SQL secara automatik menetapkan nilai lajur ini.

Kemudian banyak perkara yang terikat dengan kunci ini:

• menghubungkan jadual yang berbeza antara satu sama lain;
• carian pantas dan penapisan mengikut id;
• integriti data dalam pangkalan data (tiada rujukan kepada id yang tidak wujud);
• memadam data yang tiada siapa yang merujuk;
• dan banyak lagi yang lain.

Dengan cara ini, terdapat situasi apabila jadual mempunyai apa yang dipanggil kunci semula jadi . Ini adalah apabila terdapat lajur yang kandungannya membayangkan keunikan. Sebagai contoh, kami memutuskan untuk menambah pada jadual pekerja:

• Perintah ketibaan mereka di syarikat itu;
• Nombor cukai;
• Nombor dan siri pasport.

Kadangkala pereka pangkalan data menggunakan kunci semula jadi sebagai kunci utama, tetapi selalunya ia digunakan secara berasingan. Lagipun, rekod boleh dipadam, diubah, dan sebagainya.

Saya rasa anda membaca cerita di Internet apabila bailif menggantungkan hutang nama penuhnya pada seseorang? Ini hanya berkaitan dengan konsep kunci unik. Sangat mudah bagi bank dan bailif untuk mencari seseorang dengan nama penuh dan tahun lahir. Dan dalam 99% kes ini sudah cukup untuk mengenal pasti seseorang.

Tetapi baki <1% adalah nama penuh, dengan tahun kelahiran yang sama. Dalam kehidupan setiap daripada kita, kemungkinan besar tidak ada orang seperti itu, tetapi pada skala nasional, ada. Secara umum, jika anda menulis perisian atau mereka bentuk pangkalan data, maka adalah berguna untuk mengetahui bahawa ini juga boleh berlaku.