24.02.13 21:36 작성
·
228
0
서울특별시 무슨무슨구 무슨무슨 동이면
하나의 컬럼이아니라 여러개의 컬럼으로 나누어서 sd,sgg.. 등의 컬럼을 만들어서 하나의 테이블로 가능할것 같은데 이름 하나 때문에 테이블이 3개가 더 생기는 것 같은데 이유가 있을까요?
답변 2
0
2024. 03. 16. 18:19
결국은 코드테이블의 관리입니다. 이렇게 나누어놓으면 나중에 Group By 등을 사용해서 통계를 내는데도 유용하고 유연성과 확장성이 있지만 하나로 묶어서 관리하면 아주 경직된 로직만 사용할 수 있겠죠.
0
2024. 02. 14. 14:49
계속 보다보니 회사에 sd, sgg, adress가 다 들어있고 따로 sd와 sgg를 분리한 이유는 이것들은 고정되어있는 기준테이블이라서 그런것같습니다. 저는 그냥 다음 주소api 같은걸로 한번에 가져와서 이걸 왜 필요하지? 라고 생각했는데 만약 그게아니라 고정된 sd 서울특별시, 경기도 등등 이런 기준데이터들을 외부에서 가져오는게 아니라 우리 프로그램에서 가지고 있을때 필요한것으로 생각하면 될까요?
2024. 05. 23. 14:22
이런 유형의 질문은 아주 좋은 질문입니다. 주소를 관리하는 방법은 여러가지가 있을 수 있습니다. 다만, 해당 비즈니스 로직에서 어떤 유형을 원하는지 분석해주고 그것에 맞도록 테이블 설계를 하는 것이 원칙입니다. 저는 그 중 제가 만드는 프로젝트에서 사용한 하나의 예제를 들어드린 것입니다.
중요한 원칙은 세부적으로 나눌 수록 유연성이 커집니다. 많은 다양한 경우에 대응할 수 있다는 거죠. 예를 들어서 "마포구"에 해당되는 집계등을 낼 필요가 있다면 당연히 SGG 테이블이 있는 것이 편하죠. 만일 그냥 Address로만 받아들이면 간단해서 설계도 편하고 프로그램 구현도 편하지만 마포구만 집계를 내려면 예를 들어 xx like '%마포구%' 이런 식의 쿼리가 만들어져야 하는데 이것은 성능에도 치명적이고 이런 쿼리가 자주 많은 사람들이 사용하는 것이라면 결국 데이터베이스 서버 다운까지도 초래할 수 있는 위험한 상황도 예측됩니다.
따라서 왜 그래야 했을까? 의 질문은 매우 바람직합니다. 다만 강의의 의도가 이런 거구나 하고 생각한다음 이해가 되셨으면 그게 정답이죠. 어떤 설계에도 정답은 없습니다. 다만 구현하고자 하는 비즈니스 로직을 충분히 커버하는가, 그리고 성능에 문제가 없는가 이 두가지만 따져보면 될 것 같습니다.