2024-01-11 (24일차) - INDEX, Member 주석달기
세션만료되서 정리한게 다 날라가서 다시 정리해본다! 🥲
📅 2024-01-11, 24일차
👩💻🏠TODO - 01/11
[JDBC_AM]
- MemberController 구조 이해하기
[영상 복습]
- <작업 17, 로그인 기능 구현, 비밀번호 시도 횟수 제한>
- <작업 18, 컨테이너 도입, SQL 에러메세지 console에 보이도록 변경>
- <작업 19, 로그인 정보를 저장, member profile 기능 구현>
- <작업 20, 로그인, 로그아웃 체크>
- <작업 22, 게시물 수정, 삭제시 권한체크>
[기타]
- 벨로그 정리
[추가로 한것]
- Member랑 관련된 클래스들 로직에 전부 주석달기
DBMS
password에 관해서
- 아이디보다 비밀번호의 타입을 더 크게 하는 이유는 암호는 실제로 db에 저장될 때 사용자가 입력하는 암호가 아닌 다른방식으로 암호화 해서 저장이 된다
- 근데 사용자가 입력한 암호 보다 더 긴 암호로 저장이 된다
- 그래서 암호의 타입은 넉넉히 해두는게 좋다
loginId CHAR(100)
loginPw CHAR(200)- SHA(Secure Hash Algorithm, 안전한 해시 알고리즘) 함수들은 서로 관련된 암호학적 해시 함수들의 모음이다. (wiki백과)
INDEX
- 사전에서 단어를 쉽게 찾을 수 있는 것 처럼
- 많은 양의 데이터를 인덱스화하면 원하는 정보를 찾을 때 쉽고 빠르게 찾을 수 있음!
먼저 테스트를 해보자!
회원정보를 2배씩 늘어나게 한다. (회원 수 210만까지 늘림!)
INSERT INTO `member` (regDate, loginId, loginPw, `name`)
SELECT NOW(), UUID(), 'pw', '아무개'인덱스를 걸어보자
ALTER TABLE `member` ADD INDEX('loginId');인덱스를 삭제해보자
ALTER TABLE `member` DROP INDEX `loginId`;유니크인덱스
ALTER TABLE `member` ADD UNIQUE INDEX('loginId');loginId가 user1d1인 놈 찾고싶어
- 인덱스 걸기 전 2.5초 (98만 3040kb)
- 인덱스 걸기 후 0.002초 (124만 5184kb)
인덱스를 걸었더니, userId1를 찾을때 엄청 빨리 찾을 수 있지만 용량은 늘어나네?
Linear Search (선형탐색)
- 한줄 한줄 위에서 아래로 일일히 정보 하나하나 찾아봄
- 사전에서 단어 찾으려고 1쪽부터 한단어 한단어 한페이지씩 찾은 것과 같음
Binary Search (이진탐색)
- 반면에, 이진탐색은 트리모양이며 가지가 많이 쳐진 상태라서 찾는 속도가 빠름
- 트리가 추가 되는거라 용량이 늘어 난다.
💡인덱스화를 하면 데이터를 찾는 속도는 빠르지만, 모든 컬럼을 인덱스화 시키면 안된다. 왜? 용량이 커지니까 -> 용량은 돈! 적절히 필요한 컬럼에만 인덱스화시키자.
PRIMARY KEY
- NOT NULL, INDEX, UNIQUE가 모두 결합 된 사기케다!
Member 주석달기
Member관련 모든 클래스들 로직 이해를 위해 주석을 달았다
MemberController
MemberService
MemberDao
Session
주석 달면서 생긴 질문:
-
public boolean isLogined() -> 이 함수는 어떻게 로그인했는지 안했는지 바로 알지?
-주석에 이 질문에 대한 답 달아놈 -
MemberDao클래스 안에 Return DBUtil.어쩌구 의 역할이 뭐지? 뭘 리턴 하지?
-주석에 이 질문에 대한 답 달아놈 -
로그인기능에서 비밀번호 입력 받을때, 3번 틀리면 다시 확인하고 시도하라는 if문이 비밀번호 입력받는 로직보다 위에있는데 어떻게 이게 가능함?
- 순서가 상관이 없는게, 3번 틀리기전까지는 if문이 참이 아닐거라 if문 안을 실행하지 않고
다음로직(비밀번호 입력)으로 바로 넘어가기때문에.
hello world