[데이터베이스] mySQL DB는 대소문자를 정말 철저히 관리해야한다.

회사 홈페이지 작업을 진행하던 중

이상한 현상을 발견했다.

모든 개인정보를 암호화 보관하기 위해 암호화 작업을 하고

홈페이지에서 개인정보를 확인했더니

복호화를 안했는데도 잘나온다.

즉

예상 결과

이름 : 1231342352453463563636

실제 결과

이름: 김개똥

너무 신기해서 '설마 mySql'은 자동 복호화를 해준단 말인가? 하고 생각하곤

다음 테스트로 사용자를 입력했다.

사용자도 잘나온다. 너무 일이 잘풀리기에 이상해서 DB에 암호화로 들어갔는지 확인했다.

select * from userlist

..........10명나온다.

홈페이지의 사용자 관리 페이지엔 12명 나온다.

............................순간 내 소스가 알파고로? 하는 망상을 접고

다른 테이블을 살폈다. 없다. 어디에도 새로 넣은 가나다 사용자는 보이지 않는다.

그런데 홈페이지엔 나온다.

이게 왜그럴까 하고 소스 코드를 살피던중 탄식하고 말았다.

Select * from UserList

설마....... 하고 mysql 상에서 날려보니 12명의 데이터가 암호화되지 않은 상태로 저장되어 있었다.

놀랍게도 db에 UserList 란 테이블은 존재하지만 표시되지 않는 상태인 것이다.

나는 속으로 UserList와 userlist 구분없이 코딩한 전임자를 저주하며



........소스를 엎어버리고 있다.


시발 일이 더 늘어났어!! 도와줘 알파고!!!!!!!!!!!!!!!!!!!!

여러분도 대소문자는 꼭 구분하세요

[스트로푸]

구현 기능이 너무 잘되는데? 완벽해 신기하군 <- 일이 일어날 징조

[지크문트]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[[카즈]]

우리회사는 테이블명은 전부 소문자로 통일해서 씁니다. 그런일이 전에 있었다고해서 말이죵
필드는 대소문자 구분 안하면서 왜 테이블은 대소문자 구분하는지 참..

[익스쉐도우]

ㅋㅋㅋㅋㅋㅋㅋㅋ 알파고

[요다 아빠]

lower_case_table_name 옵션을...

[I루시에드I]

이상하다 왜 안 되지? VS 이상하다 왜 잘 되지?

[사사키-하이세]

구분 안하도록 설정하면 되지 않나요???