사용자에게 안내가 필요한지 여부를 식별하는 데 is_new를 사용하는 것처럼 사용자 테이블에 직접 행을 추가하기만 하면 새 테이블을 만들 필요가 없습니다. 물론 일부 사용자 행동을 초기화하는 등 사용자의 선택을 기록해야 하는 경우에는 이러한 내용을 기록하기 위한 새 테이블을 생성하고 동시에 user_id 인덱스를 생성하고 일부 열을 추가해야 합니다. . 태그만 하세요. 나는 개인적으로 그것이 과잉이 아니라 올바른 접근 방식이라고 생각합니다.
API에 접속하면 백엔드에서 사용자에게 특정 마크가 있는지 확인하고 이를 프런트엔드로 반환한 다음 프런트엔드에서 렌더링하는 것이 일반적인 관행입니다. 백엔드 관점에서 봤는데, 프론트엔드에 흑마술이 있는 건지 모르겠네요.
사용자에게 안내가 필요한지 여부를 식별하는 데 is_new를 사용하는 것처럼 사용자 테이블에 직접 행을 추가하기만 하면 새 테이블을 만들 필요가 없습니다. 물론 일부 사용자 행동을 초기화하는 등 사용자의 선택을 기록해야 하는 경우에는 이러한 내용을 기록하기 위한 새 테이블을 생성하고 동시에 user_id 인덱스를 생성하고 일부 열을 추가해야 합니다. . 태그만 하세요. 나는 개인적으로 그것이 과잉이 아니라 올바른 접근 방식이라고 생각합니다.
API에 접속하면 백엔드에서 사용자에게 특정 마크가 있는지 확인하고 이를 프런트엔드로 반환한 다음 프런트엔드에서 렌더링하는 것이 일반적인 관행입니다.
백엔드 관점에서 봤는데, 프론트엔드에 흑마술이 있는 건지 모르겠네요.
제 제안 중 하나는 사용자가 관련 작업을 수행했는지 확인하는 것입니다. 예를 들어 사용자가 처음으로 새 시험지를 생성하면 새 시험지를 생성하는 초보자에게 프롬프트가 제공되고, 사용자가 처음으로 시험지에 답하면 답안지에 프롬프트가 표시됩니다.