Head First SQL (Korean Edition), 2nd Edition

제8장. 키 와 데이터 관계: 신중한 테이블 설계

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

모든 아키텍트와 디자이너 여러분께. 여러분은 그동안 별다른 고민 없이 테이블을 만들어 왔습니다. 물론, 그렇게 해도 테이블은 잘 작동합니다. CRUD 작업을 모두 수행할 수 있고, 필요에 따라 아무리 복잡한 SELECT 문도 작성할 수 있습니다. 하지만 데이터가 늘어날수록, WHERE 절을 더 간단하게 만들었더라면 좋았을 WHERE 절을 더 간단하게 만들 수 있었을 텐데 하는 아쉬움이 생기기 시작할 것입니다. 아니면 단일 테이블만으로는 더 이상 용량이 부족해져, 데이터 구조를 약간 개편해야 할 수도 있습니다. 데이터가 점점 더 복잡해질수록 핵심은 테이블을 원자적 으로 만들고, 데이터를 여러 개의 관련 테이블로 나누는 것입니다. 누가 알겠습니까? 어쩌면 최적의 청사진이 고층 빌딩 전체의 설계도로 이어질지도 모릅니다. 계속 읽어보세요.

산호세(San Jose)가 어느 주에 속하는지 알고 계신가요?

실수는 일어날 수 있지만, 다행히 애비는 5장에서 UPDATE 문을 배웠습니다. 이를 사용하여 산호세의 state 값으로 “CA”를 추가할 수 있습니다:

생각해 볼 문제

애비의 UPDATE 문은 테이블의 두 행을 변경했습니다. 왜 그런 일이 일어났을까요? UPDATE 실행하기 전에 그녀는 무엇을 했어야 했을까요?

도시 혼동

애비가 모범 사례를 따랐다면, UPDATE 문 실행 전에 SELECT 문에서 를 테스트했을 것입니다. 이제 그녀는 SELECT 문을 실행하여 무엇이 변경되었는지 확인합니다.

애비가 WHERE 절을 작성할 때, 도시 이름이 단 한 행과만 ...