join 문제 풀이2 문제1(self join) 질문

안녕하세요. 윤현지님두 방식 모두 같은 결과가 나오는데요.현지님이 작성하신 쿼리가 from 절의 메인 테이블을 기반으로 하기 때문에 더 직관적이라 생각합니다.잘하셨어요 🙂감사합니다.

9. 인덱스2.pdf 중에서

헝헹행님 감사합니다 🙂다음 패치에 반영할게요^^!

자바 equals() 메소드에 대한 물리적 동일성, 논리적 동등성 질문

안녕하세요. zeler1004님AI 퀴즈를 인프런 플랫폼에서 AI를 통해서 자동화해서 제공하고 있는 기능인데요.기능이 아직 완벽하지는 않은 것 같아요.자바의 경우 기본적으로 ==은 물리적 비교, equals()는 논리적 비교로 보는 것이 맞습니다.다만 equals()를 구현하지 않으면 Object가 제공하는 기본 equals()를 사용하게 되고, 해당 구현의 기본 기능은 ==와 같은 물리적 비교입니다.감사합니다.

대리키의 외부 노출에 대한 질문을 하고 싶습니다.

안녕하세요. index님AI 인턴이 잘 답변해주었는데요. 추가로 보충을 드릴게요.우선 1번은 반드시 필수로 진행해야 합니다.그럼에도 불구하고 가끔 1번이 누락되어서 무작위 숫자 공격에 뚫릴 수 있는데요. 보안이 중요한 부분이라면 이럴 때를 대비해서 말씀하신 2번을 고려하면 됩니다 🙂감사합니다.

오타 제보

donggyu00.oh님 고맙습니다 🙂다음 패치에 반영할게요^^!!

강의록 오타 제보

dev.rudevico님 고맙습니다 🙂다음 패치에 반영할게요^^

대리키 사용과 정규화

안녕하세요. 강일모님제3 정규형을 일반적으로 설명하다보니, 설명이 부족한 부분이 있었네요.다음 내용을 메뉴얼에 보충해 두었으니 참고해주세요 🙂감사합니다. 제3 정규형 심화: 후보 키와 이행 종속여기서 실무에서 많이 헷갈려 하는 부분을 하나 짚고 넘어가겠다.member 테이블을 생각해 보자. member_id PK, login_id UK, password, email UK)이 테이블에는 다음과 같은 종속 관계가 있다.* member_id → login_id* login_id → password, email이 관계가 member_id → login_id → password 처럼 보여서 이행적 함수 종속으로 오해할 수 있다.결론부터 말하면, 이것은 제3 정규형 위반이 아니다."왜?"제3 정규형이 막으려는 진짜 문제는, '키가 아닌 일반 속성'이 '다른 일반 속성'을 결정하는 상황이다.앞선 orders_2nf 예시order_id → member_id → member_name)에서는 member_id가 orders_2nf 테이블의 키가 아닌 '일반 속성'이면서 member_name이라는 '일반 속성'을 결정했기 때문에 문제가 되었다.하지만 member 테이블의 login_id는 '일반 속성'이 아니다.#### 후보 키 (Candidate Key)데이터베이스에는 행을 유일하게 식별할 수 있는 여러 '키'들이 있다.* 후보 키 (Candidate Key): 튜플(행)을 유일하게 식별할 수 있는 속성.* 기본 키 (Primary Key): 여러 후보 키 중 대표로 선택한 키.member 테이블에서 member_id, login_id, email은 모두 UNIQUE하므로 행을 유일하게 식별할 수 있다. 따라서 이 셋은 모두 후보 키다.login_id는 '일반 속성'이 아니라 당당한 '후보 키' 자격을 가지고 있다.키(후보 키)가 다른 속성을 결정하는 것은 지극히 정상적이고 바람직한 관계다.따라서 login_id → password 관계는 후보 키가 일반 속성을 결정하는 것이므로, 제3 정규형에 전혀 위배되지 않는다. 이 테이블은 이미 제3 정규형을 만족하는, 잘 설계된 테이블이다.

강의자료 까마귀발 잘못된거 아닌가요?

트리님 감사합니다 🙂다음 버전에 패치할게요^^!

runnable 질문

안녕하세요. 김지윤님이 부분은 자바 중첩 클래스와 내부 클래스에 대한 이해가 부족하기 때문입니다.자바 중급1편 중첩 클래스, 내부 클래스1,2를 복습해주세요 🙂감사합니다.

자바가 아닌 다른 언어에서도

안녕하세요. 박살님네, 괜찮습니다. 스레드가 생성되고, 시작되고, 중간에 다른 작업으로 인해 대기하며, 결국 종료되는 큰 그림을 이해하고 테스트하는 목적이라면 닷넷으로 코드를 작성해도 동일한 원리를 확인할 수 있습니다.결국 스레드라는 것이 OS가 제공하는 것 기반이니까요.다만, 특정 상태(BLOCKED vs WaitSleepJoin)를 정밀하게 추적하거나 각 플랫폼의 스레드 관련 API(synchronized vs lock)의 미묘한 동작 차이를 분석하는 것이 목적이라면, 해당 플랫폼에 맞는 도구와 코드로 테스트하는 것이 가장 정확합니다.감사합니다.