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:
id_tugas | tugas_desc | tarikh akhir | id_pekerja | emp_name | emp_occupation |
---|---|---|---|---|---|
1 | Betulkan pepijat pada bahagian hadapan | 2022-06-01 | 1 | Ivanov Ivan | Pengaturcara |
2 | Betulkan pepijat pada bahagian belakang | 15-06-2022 | 2 | Petrov Petr | Pengaturcara |
7 | Nikmati kehidupan | (NULL) | 4 | Rabinovich Moisha | Pengarah |
3 | Beli kopi | 2022-07-01 | 5 | Kirienko Anastasia | Pengurus pejabat |
4 | Beli kopi | 2022-08-01 | 5 | Kirienko Anastasia | Pengurus pejabat |
5 | Beli kopi | 2022-09-01 | 5 | Kirienko Anastasia | Pengurus pejabat |
8 | Nikmati kehidupan | (NULL) | 6 | Vaska | kucing |
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.