별칭

사용 가능

열 이름 변경

열 이름도 처리해야 합니다. 그렇지 않으면 name과 id라는 이름을 반복하지만 서로 다른 데이터를 포함합니다. 반면 동일한 데이터를 포함하는 첫 번째 id 열과 employee_id 열이 있습니다.

필요한 열만 있는 쿼리를 작성하고 동일한 이름을 가진 열의 이름도 바꾸겠습니다.

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

그리고 이 쿼리의 결과는 다음과 같습니다.

task_id task_desc 마감 시간 employee_id emp_name emp_occupation
1 프런트엔드의 버그 수정 2022-06-01 1 이바노프 이반 프로그램 제작자
2 백엔드의 버그 수정 2022-06-15 2 페트로프 페트르 프로그램 제작자
7 즐거운 삶 (없는) 4 라비노비치 모이샤 감독
커피를 사다 2022-07-01 5 키리엔코 아나스타샤 사무실 관리자
4 커피를 사다 2022-08-01 5 키리엔코 아나스타샤 사무실 관리자
5 커피를 사다 2022-09-01 5 키리엔코 아나스타샤 사무실 관리자
8 즐거운 삶 (없는) 6 바스카 고양이

좋습니다. 이해할 수 없는 열 이름 문제가 성공적으로 해결되었습니다. 쿼리가 약간 길어졌지만 결과 테이블에서 모든 것이 명확합니다. 추가 열이 없습니다.

테이블 별칭

때때로 테이블 이름이 너무 길어서 쿼리에서 많은 공간을 차지합니다. 따라서 SQL 작성자는 열의 경우와 같이 가독성을 향상시키기 위해 테이블 ​​별칭을 지정하는 기능을 제공했습니다.

별칭(테이블 별칭)의 일반적인 형식은 다음과 같습니다.

FROM table1 alias1, table2 alias2

짧은 별칭을 사용하여 이전 쿼리를 다시 작성해 보겠습니다.

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

가독성이 약간 떨어졌지만 이는 테이블 이름이 처음에 단순하고 명확했기 때문입니다. 다음과 같을 수도 있습니다.

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 

이 경우 별칭은 이미 유용합니다. ;)

기본 키

그리고 테이블에 대한 중요한 정보가 하나 더 있습니다. 작업 테이블에 employee_id 열이 있었던 것을 기억하십니까? 이를 통해 직원 테이블에서 직원 ID를 참조했습니다.

한 테이블에서 다른 테이블의 행을 참조하려면 참조된 테이블에 기본 키( PRIMARY KEY )라고도 하는 ID가 있는 열이 있어야 합니다 .

대부분의 경우 이것은 값 유형이 int 인 특별히 추가된 열입니다 . 테이블에 레코드를 추가할 때 SQL은 이 열의 값을 자동으로 설정합니다.

그런 다음 많은 것들이 이 키에 연결되어 있습니다.

  • 서로 다른 테이블을 서로 연결;
  • ID로 빠른 검색 및 필터링;
  • 데이터베이스의 데이터 무결성(존재하지 않는 ID에 대한 참조 없음)
  • 아무도 참조하지 않는 데이터 삭제
  • 그리고 많은 다른 사람들.

그런데 테이블에 소위 자연 키가 있는 경우가 있습니다 . 내용이 고유성을 암시하는 열이 있는 경우입니다. 예를 들어 직원 테이블에 다음을 추가하기로 결정했습니다.

  • 회사 도착 순서;
  • 세금 번호
  • 여권 번호 및 시리즈.

때때로 데이터베이스 설계자는 자연 키를 기본 키로 사용하지만 대부분 별도로 사용됩니다. 결국 레코드는 삭제, 변경 등이 가능합니다.

집행관이 자신의 이름을 딴 사람에게 빚을 졌다는 이야기를 인터넷에서 읽었습니까? 이것은 고유 키의 개념과 관련이 있습니다. 은행과 집행관은 이름과 생년월일로 사람을 검색하는 것이 매우 편리합니다. 그리고 99%의 경우 이것은 사람을 식별하기에 충분합니다.

그러나 나머지 1% 미만은 출생 연도가 같은 전체 이름을 딴 사람들입니다. 우리 각자의 삶에는 그러한 사람들이 없을 가능성이 높지만 국가적 규모로는 있습니다. 일반적으로 소프트웨어를 작성하거나 데이터베이스를 설계하는 경우에도 그럴 수 있음을 아는 것이 유용합니다.

코멘트
  • 인기
  • 신규
  • 이전
코멘트를 남기려면 로그인 해야 합니다
이 페이지에는 아직 코멘트가 없습니다