아래 설명했듯이 mysql은 한 테이블에 3천개 이상의 칼럼을 등록할 수 있다.
하지만 칼럼마다 데이터의 크기가 클 경우
예기치 못 하게 2900개 정도의 칼럼에서 막힐때가 있음
이럴때 우리 si회사는 우리만의 디비 정규화 라는 작업을 시작한다.
만약 주문정보 api에 넘어오는 json 데이타가 있다 가정해보자
{ 주문자 : 프갤럼 , 상품명 : 코딩책 , 가격 : 10000 }
이걸 보통같으면 각각의 주문자, 상품명, 가격 칼럼을 만들어서 디비에 저장한다.
하지만 si의 정규화가 시작되면 json 그 자체를 디비에 넣는다
칼럼명 : order_json
데이터 : { 주문자 : 프갤럼 , 상품명 : 코딩책 , 가격 : 10000 }
그 후 필요할땐 저 json 그자체를 그대로 뽑아와서 파싱해서 쓰면됨
이렇개 저장하면 마이에스큐엘의 칼럼수 제한이 간당간당해도
한 테이블에 더 많은 정보를 저장할수 있다.
- dc official App
일단 db에 쳐밖고 본다 = si 종특
ㄹㅇ ㅋㅋㅋㅋㅋㅋㅋ
1400
무식추 ㅋㅋㅋ - dc App
저게시발좋아보이나 ㅋㅋ절대하면안될거같은데 ㅋㅋ
이거 몽고디비아니냐?ㅋㅋ
이왜념?
저짓거리하면 개병신
조인 어케함? ㅋㅋ
조인할 필요가 어딧음 한 테이블에 모든 칼럼이 다 있는데 - dc App
저러면 데이터 수정할려면 데이터 뽑고 파싱하고 수정하고 제이슨으로 바꾸고 업데이트 해야됨?
ㅇㅇㅇㅇㅇ - dc App
그거 함수를 모듈화를 해놔서 어떤 프로젝트를 하던 그 모듈에서 함수 복사해서 붙여넣기하면 그리 어렵지도않음 - dc App
저럴거면 걍 몽고디비쓰면 안됨??
si회사는 안전성이 젤 중요하다. 아직도 스프링부트 안쓰고 레거시스프링 기반 전자정부 프레임워크 쓰는거보면 모르겟냐? 몽고디비라는 신기술 썼다가 디비 뻑나면 금융권이나 공공기관 데이터가 날라가는건데 누가감당함 - dc App
저거 유용한데 븅신들은 구린줄암
이.. 이게 무슨?
존나 심박하긴한데 데이터 수정할때 좆될듯
존똑이네 ㄷㄷㄷ
그런대 한 테이블에 많아도 100개 정도 쓰던데 3000개 쓰는 경우도 있음? 신기하네
이거실제로 nosql디비에서 많이 쓰는전법임 조롱할겦아니라 요즘 트랜드다
무릎치고간다
sql과 nosql의 단점만을 모아 놓았네 역시 조선 si 짱짱
필드값 수정하려면 post해야하냐 put해야하냐?ㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋ
json으로 설계잘해서 넣으면 ㄱㅊ은방법아니노?
애미 ^^ㅣ발 아무튼 돌아만 가면 되는거냐고 ㅋㅋ
아무튼 돌아감
포포몬쓰를 희생ㄷㄷ
집계하고 싶을때부터 지옥 시작이네 개별 row단위로만 조회 갱신 이뤄지면 괜찮을듯 ,
이거 pgsql에서 hstore 확장 지원하는거랑 비슷하네