[취업준비일지] - 51 - 스터디 프로젝트 12일차

오늘 진행할 작업은
1.검색조건 변경 on/off
2.상단 버튼부분 정리
3.기간부분 input 년,월,주 넣는 방식 고민(년=20**, 월=0x/11/12,주=1~5 유효성검사?)
4.임시 api 데이터 받는 axios 생성해두기

검색조건 변경 아이콘을 누를 경우 검색조건 창이 나타나는 형태(피그마 구현)로
on/off 기능을 구현하려고 헀는데 이를 위해서는 usState가 필요했는데
여기에 type을 주기 위해서는 useState<boolean>(false);형태로 줘야헀다.

이렇게 만든 state를 함수로 다룰 때는 type 지정이 필요없었지만
props로 넘겨주려고 하니 '이 호출과 일치하는 오버로드가 없습니다.'라는
에러메세지가 출력되는 것을 볼 수 있었다.

이건 props의 타입지정이 되지 않아 생기는 문제였는데
styled-components 파일에서 아래와 같이 들어갈 수 있는 
값들의 타입을 미리 선언하고 조건부 사용을 할 수 있게 한 다음
interface Props {
  onOff?: boolean;
  aaa? : string;
  bbb? : number;
}
export const FilterContainer = styled.div<Props>``처럼
props를 사용할 때 type을 설정해주면 정상적으로 작동하는 것을 볼 수 있다.

Props 전용 interface로 styled-components의 props를 관리하자

구현을 하다가 검색 조건에 대해 고민하면서 api를 확인해보니
검색 조건에 맞는 api는 존재하지 않는다는 사실을 알 수 있었다.
api상에서 제공하는 것은 신간, 베스트셀러 여부였으며
그 외에 검색기능 자체가 존재하지 않는 상태였다.

일단 api가 없는 동작을 추가하기에는 서버와 통일감이 부족하기 때문에
검색 컨테이너는 봉인시키고 아마 월요일에 있을 회의 때 이야기를 해야 할 것 같고 개별 검색도 임시로 멈춰야 할 것 같다.

api페이지가 수정이 안된건지 회의 후 엄청나게 작업을 많이 하시는 것을 봤는데
회의 때 말한 내용이 들어있지는 않는 것 같았다.
프론트엔드에서 처리가 가능하긴 한 작업들인데
이걸 서버에서 되도록 하는게 좋다고 했기 때문에 건드리기 애매하다.

책 리스트를 뿌릴 때 내가 보유하고 있는 책인지 각각 체크해야 하는 것이
말로는 간단해 보일지 모르지만 무한스크롤로 출력된 책이 100권이고
내가 위시리스트, 나의 서재에 보유한 책이 각각 50, 30권이라고 친다면
현재 출력되는 모든 책들이 위시리스트 한바퀴, 나의 서재 한바퀴로 
80건의 조회가 필요하며 거기에 100권이기 떄문에 8000건의 조회가 필요해지는데
이는 책의 수량이 많아지고 스크롤을 내릴수록 문제가 생길 여지가 있다고 본다.

아무래도 비관계형인 MongoDB로 
join형태로 필요한 데이터에 접근하려고 하다보니 문제가 생기는 것 같지만 
그렇다고 SQL쪽으로 넘어가려고 해도 데이터 수정보다는 조회의 비중이 크기 때문에 속도를 생각하면 noSQL이 유리하기도 하다.

확실한건 현재 상태로는 다른 페이지(홈,위시리스트,보유도서)들과의 연계가
상당히 복잡해질 것 같다는 생각이 든다.

상단 레이아웃을 정리하는 도중 event에 많은 type들이 있다는 것을 확인하고 
이것저것 사용해보고 form을 이용하는 방법도 찾아봤지만 단일 함수 사용이
훨씬 더 편리한 것을 보고 결국 state를 사용해 검색 문자열을 관리했다.

내일은 api소통을 진행해볼 수 있을 것 같고
모달창도 완성이 거의 되셨을 것 같은데 사용하면 어떻게 기능은 될 것 같다.



1.SQL(관계형 DB)은 관계를 통해 여러 테이블에 분산되며 스키마에 따라 테이블에 저장된다는 특징이 있다.

테이블마다 지정된 스키마가 있기 때문에 
스키마를 준수하지 않은 데이터는 추가될 수 없으며
각 테이블마다 중복 없는 데이터 관리와 무결성이 보장된다.

하지만 스키마를 사전에 계획해야 하며 수정이 어려우며
각각의 관계로 연결되기 때문에 복잡한 조인을 사용하는 경우가 생기고
수직적 확장만 가능하기 때문에 한계가 명확하다는 단점이 있다.

구조는 바뀌지 않지만 내부 데이터가 자주 변경될 수 있으며
관계적으로 동시에 데이터가 요구되는 상황에서 효율적이다.


2.NoSQL(비관계형 DB)은 트리 구조형태로 데이터를 관리하며
관련 데이터들을 공통된 컬렉션에 추가하는 방식으로 사용한다.

필드, 데이터 추가에 규칙이 없기 때문에 편하게 추가할 수 있으며
스키마의 고려 없이 편하게 전체를 수정할 수 있고
목적에 맞는 설계를 통해 한번이 호출로 데이터를 사용할 수 있다.
또한 수직 및 수평적 확장이 자유롭다는 장점이 있다.

하지만 하나의 컬렉션에서 필요 정보를 다 받아올 수 없는 경우
여러 컬렉션 동시 접근에서 중복이 발생할 위험이 높으며
같은 형태에서 잦은 데이터의 수정이 필요할 경우 비효율적이며
데이터 구조가 맞지 않을 경우 더 비효율적일 수 있다.

구조적 변경이 발생할 수 있거나 내부 값 수정이 적은 경우
또는 수평적 확장이 요구되는 경우 등에서 효율적이다.





(1).백준 1032 명령 프롬프트는 디렉토리 경로들을 통합하는 문제로
경로 중 글자가 다를 경우 통합을 위해 '?'로 대체하여 출력한다.

각 문자열들의 i번째 글자를 조회해 모두 같을 경우 그 글자를 str에 추가하고
하나라도 다른 글자가 있을 경우 '?'로 변경 후 break처리해 
str에 '?'가 즉시 추가되게 만들 다음 최종적으로 str을 출력했다.

let input = `3
c.user.mike.programs
c.user.nike.programs
c.user.rice.programs`.split('\n')

let str = ''
for(let i = 0 ; i < input[1].length ; i++){
    let el = input[1][i]
    for(let j = 1 ; j < input.length ; j++){
        if(el !== input[j][i]){
            el = '?'
            break
        }
    }
    str += el
    
}
console.log(str)