컬럼도 레코드 수도 정말 적은 테이블이 있다면 굳이 db상에 안만들어놓고 자바코드 처리해도 괜찮을까요?

Question

예를 들어, 게시물 카테고리 테이블(게시물 카테고리 번호, 게시물 카테고리 이름) 이런 컬럼 2개짜리 테이블에 많아봤자 레코드는 5개, 정말 많아봤자 10개 미만으로 들어있고 들어있는 값의 내용이 변할 일도 거의 없다면 테이블을 굳이 만들 필요가 있을까요? 그냥 자바의 enum형이나 혹은 프로젝트 안에 간단한 json파일 등을 만들어놓고 그걸 읽어서 사용하는 방법을 쓰는건 별로일까요? 어플리케이션 내장객체는 어디에 활용하시나요? 게시판 메뉴 구조가 좀처럼 변할 일이 없다면 게시판 메뉴, 혹은 위의 게시판 카테고리 등을 트리나 맵으로 만들어서 application 내장객체에 넣고 써도 될까요? 사용자마다 이런 값들을 일일이 요청-db조회-응답 받을 수 있게 해주는 것도 비효율적인 것 같은데스프링 어플리케이션이 시작될 때 db 혹은 열거형, 설정파일 등에서 읽어와서 application 내장 객체에 넣고 쓸 수 있도록 하는건 현실적이지 못한 부분이 있을까요?

ambp · Accepted Answer

어차피 자주 안 바뀌는 값이라면 db에서 조회하는 식으로 구현해도 서버 뜰 때 한 번만 할 거라서 성능 차이는 무의미 할 거 같은데요?

Henry7 · Answer

바뀔 일이 거의 없으면 db는 없어도 됩니다.

Iskra · Answer

ambp 그 경우에는 application 내장객체를 사용해도 무방할까요?

Iskra · Answer

레인3 잠깐 사이에 다른 모 사이트의 테이블 설계를 보다보니 게시판의 순서나 메뉴, 카테고리의 순서가 바뀔 경우도 생각을 해야 하는 것 같네요 만약 게시물 카테고리의 순서를 바꾸기 위해 카테고리 번호들을 바꿔준다면 그걸 참조하는 게시물 테이블에 들어있는 값들도 싹 바꿔야 될 수도 있다는 생각이 들었네요 그런 만약의 가능성을 고려해서 db에 넣고 컬럼도 추가해서 하겠습니다...

ambp · Answer

방법보다는 이유가 합리적이지 않다고 생각합니다. 자주 안 바뀔 데이터고 크기가 작고 부트 타임에 한 번 불러오는 거라면 db 성능이 주는 cost는 크지 않을 거 같은데요?

Llux lux · Answer

따로 관리하는게 더 비효율적일수도 있죠.말씀하신것처럼 관리자 페이지에서 순서를 바꾼다던지 노출여부를 변경하거나 카테고리 관리자를 지정한다던지요.

더미 · Answer

그런건 보통 설정에만 씁니다.

컬럼도 레코드 수도 정말 적은 테이블이 있다면 굳이 db상에 안만들어놓고 자바코드 처리해도 괜찮을까요?

7개의 답변

#enum 목록