🔧 카티션 곱과 NATRUAL JOIN 🔧 카티션 곱 SELECT a,b FROM A,B WHERE A.dept_name = B.dept_name; 두 릴레이션의 모든 tuple들에 대한 조합을 가진 릴레이션을 생성한다. 🔧 Natural Join —> MySQL 의 NATURAL JOIN 카티션 곱과의 차이 : 두 릴레이션의 스키마에서 나타나는 {{ 공통속성 ] 의 값이 같은 Tuple의 짝만 } } 고려 한다. 결과 릴레이션에서는, { 하나의 속성 } 으로 통합된다. 즉, A relation에 name attribute가 존재, B relation에 name attribute가 존재했다면, 결과 릴레이션에 존재하는 name attribute는 하나다.( 두 개가 아니다 ) 🔧 속성을 잘못 동일시 하는..

이번주 코테가 여러개 있어.. SQL 공부를 다시 하고 있다. 그 김에 팀프로젝트에서 알게 되었던 내용에 대해 다시 정리해 보았다. 🔧 SELECT DISTINCT 와 ORDER BY 가 함께 쓰이는 경우 정렬은 예상하지 못하게 일어난다 팀프로젝트를 하는데, 팀원 분의 쿼리에서 예상했던 결과가 나오지 않고 있었다. 나 역시 해당 쿼리로 해결 할 수 있을 거라 생각했는데 원하는 결과가 나오지 않았고, 이를 해결하는 과정에서 SELECT DISTINCT 와 ORDER BY 가 함께 쓰는 경우, 주의해야 함을 알게 되었다. 🔧 당시 상황 study - book 은 다대일 관계 ( study -> book 으로 book 의 pk 를 참조하고 있다 ) 쿼리로 가져오려고 한 것 : 최근에 스터디가 생성된 책 목록을..

라이징캠프에서 DB 설계 과제를 하게 되었다. 이 과정에서 조건이 존재했다 1. 모든 테이블에는 createAt,updateAt, status 속성을 갖도록 한다. 2. 한 방 쿼리 라는 것을 작성하는데, 여기서 한 방 쿼리 라는 이름이 붙은 이유 : 하나의 화면에 대한 것을 출력 시키기 위한 쿼리를 작성한다 . 이 때, 최대한 "하나의 쿼리만" 날리도록 작성한다. 나는 여기서, "status" column을 왜 가져야할까 에 대해 고민했다. 대충, 이 status column을 둔다면, 실제 레코드를 테이블에서 제거하는게 아니라 status만을 바꾸게 될 것이라는 생각을 했다. 이렇게만 보면 좋아보였지만, 이는 이제까지 내가 간단한 프로젝트를 만드는데 있어 해오던 과정은 아니었다. 또한 모든 테이블에 ..