정리하게 된 배경이전에 업무 도중 read lock이 걸린 적이 있었다. 내가 걸린 것은 아니었긴 한데..한 테이블에 한 명의 개발자는 update를 1명의 다른 개발자는 select문 하고 있는 상황인데 select 때 commit을 하지 않으면서 lock이 걸림 결국, select 때, 꼭 트랜잭션을 끝내기 위해 rollback이나 commit을 해줘야 한다고 한다.나는 이전까지 update, delete, insert만 조심하면 되는 줄 알았는데 select도 조심해줘야 한다는 사실이 좀 놀라웠다.그래서 그때, 찾아보고 정리해야지 하다가 읽어보기만 하고 정리는 따로 하지 않게 되어 글또 7회차 글 낼 때도 되었고 해서 전체적인 lock에 대해 정리하고 그리고 실무에서 데이터 베이스 테이블은 거의 외..

회사 테이블을 찾아보다 보니 외래키가 하나도 설정되지 않은 것을 보았다. 이렇게 외래키를 실무에서 쓰지 않는 이유는 뭘까?그것에 대해 답변이 달려 있는 것을 보게 되었다.외래키를 실무에서 잘 사용하지 않는 이유와 대안실무에서 외래키를 쓰지 않는 이유 - 어느 강의의 답변외래키를 사용하는 이유는 데이터의 정합성을 유지하기 위해서 사용을 하는데요.하지만 실무에서는 수작업으로 데이터를 다루는(수정, 생성) 경우가 빈번합니다. 이때 테이블의 관계상 데이터 생성 순서가 맞지 않으면 에러가 발생하기도 하고, 어쩔 수 없이(e.x, 데이터 재생성을 위한 등) 데이터(자식 테이블)를 삭제 하는 경우 CASCADE 옵션이 걸려 있다면 부모 테이블 데이터가 삭제가 되는 참사가 발생하기도 합니다.문제가 생겨 빠르게 수작업을..