DB 테이블 설계, 다중 auto increment

Question

안녕하세요 선배님들,DB 설계에 대한 궁금증으로 또 질문을 남기게 되었습니다.mysql 8 버전을 사용하고 있습니다.특정 컬럼을 기준으로 auto increment를 적용하여 독립적으로 증가하는 값을 사용하고자 합니다.예를 들면 게시판마다 게시판의 고유 컬럼명에 따라서 각 게시글 id가 1부터 시작하도록 하는 것과 같습니다.mysql myisam을 사용할 경우 복합키로 사용하여 위 방법이 적용 가능한 것으로 알고 있습니다. innodb는 불가능한 것으로 알고있지만, innodb를 사용하고자 합니다.innodb를 사용할 경우, insert시 max&#43;1을 해주는 방식은 게시글이 삭제되었을 때, 다시 insert하는 과정에서 삭제된 게시글의 id로 다시 추가되게 되므로, 이 문제를 해결하기 위해서 별도의 index counting table을 사용할 수 있다고 생각됩니다.다만 이 경우 예시를 게시글로 들었지만, 사실 대부분의 테이블이 특정 컬럼을 기준으로 1부터 값이 시작해야 합니다. 그렇다면 모든 테이블의 인덱스를 관리하는게 비효율적인 설계이지 않을까? 하는 고민이 듭니다.[질문]위와 같은 상황에서, 선배님들이 현업에서는 어떤 방식으로 &#34;여러 테이블에 고유 컬럼명에 따라서 각 id가 1부터&#34; 시작하도록 설계하시나요?myisam과 innodb를 병행해서 사용하는 경우가 간혹 있을까요? 공부하면서 찾은 정보에는 일관성을 유지하는게 좋다는 점과 innodb를 권장하는 내용이 많았습니다.mysql의 시퀀스 테이블을 만들어서 사용하는 방법이 있는데, 혹시 위 문제점에 적합한 해결 방법일까요? 다양한 정보와 gpt를 통해서 검색하고 있지만 쉽게 이해되지 않아서 질문을 남기게 되었습니다.일전 질문과 마찬가지로 한 개의 통합된 사이트에서 고객사별로 사이트를 open 해주고 각 고객사들이 사이트를 독립된 서비스를 사용하는 사이트의 DB를 설계하는 것이 목표입니다.선배님들의 고견을 부탁드립니다.감사합니다..

쿠잉 · Accepted Answer

이전글과 이번글의 댓글을 보고 요건을 정리해봅니다.- 한 개의 통합 사이트에서 고객사별로 도메인 또는 코드를 사용해서 고유한 ID를 지정하고, 통합된 서비스지만 고객사별로 독립된 계정관리/게시글 관리 등을 사용하고자 함, 통합 사이트의 관리자 페이지에서 각 사이트에 대한 정보를 조회/관리/삭제 하고자 함- 고려하는 부분이 게시판외에도 여러 테이블(회원, 등급 등)이 특정 컬럼(사이트를 나누는 code)을 기준으로 각자 seq가 1부터 시작되어야 하다보니 여러 개의 인덱스 테이블을 모두 만드는게 올바른 방법이 아닌 것 같다는 생각이 들었습니다.의견1) 고객사별 게시판 : 이건 네이버 카페를 참고하시면 이해가 되실것 입니다. 무슨말이냐면 게시글 클릭하기 전에 마우스를 가져다대면 링크주소가 보이실건데요 글마다 주소를 봐보시면 느낌이 오실것 입니다.전체 글 보기로 보면 카페내 게시판이 다양하게 있을것인데요 게시글 번호(id)는 게시판 유형과 상관없이 증가 합니다.질문게시판 : 저 질문 있어요 | article_no:51자유게시판 : 안녕하세요 ... | article_no : 50가입인사게시판 : 가입했어요 | article_no:49즉 db테이블로 보면 1개의 테이블을 사용하는 것 입니다. 그럼 유추해볼수 있는 모델은 아래와 같습니다.id(auto_increment) | 게시판명(또는 게시판 코드) | 게시물 제목 | 게시물 내용 | 작성자 계정명(또는 계정ID(숫자)) | 작성일 | 수정일 | 요구사항에 맞게 컬럼을 하나더 추가하면id(auto_increment) | 회사명(또는 회사코드) | 게시판명(또는 게시판 코드) | 게시물 제목 | 게시물 내용 | 작성자 계정명(또는 계정ID(숫자)) | 작성일 | 수정일 | 가장 간단하게 시작하는 것은 이렇게 게시판을 통합해서 1개 테이블로 사용하는 것 입니다.물론 댓글 쓰기가 가능한 형태라면 댓글 테이블은 별도로 쓰고요서비스가 커져서 고객사가 너무 많고 1개 테이블이 크기가 커져서 성능적 관리적인 부분을 고려해야한다 라면 고객사별로 테이블을 나누는 것 입니다.dcinside 사이트를 가셔서 갤러리를 들어가보세요 거기의 게시물 번호는 갤러리 별로 증가합니다. 즉 dcinside는 갤러리별로 테이블을 별도로 사용한다고 예상할수 있는것이지요이처럼 갤러리를 하나의 고객사로 보고, 고객사별 테이블을 분리하는 방법이 나중에 규모가 커지면 고려할수도 있습니다.다만 보통의 경우 테이블 1개로 사용하고 테이블의 크기가 어느정도 커진다고 해도 MySQL 리스트 파티션을 이용하거나 range 파티션을 이용하는 파티션 테이블을 사용하는 전략을 고려할 수 있기 때문에 고객사별로 테이블의 분리는 고려대상이 되지 않을수도 있습니다.dcinside 사이트를 예를 들어 갤러리 1개의 글 작성과 읽기가 너무 헤비하여 서버의 부하가 많다 라고 가정할 경우 물리적으로 별도 서버를 분리를 고려한다면 이와 같은 경우 고객사별로 물리 서버가 분리되면서 테이블을 각각 사용하는 형태도 될 수 있습니다.어쨋든 처음은 1개 테이블로 쓰셔도 될 것 같습니다.

Clickin · Answer

myisam이면 로우 하나 넣으려고 테이블 전체에 락이 걸릴텐데요여러 유저가 동시에 데이터를 발생시키는 게시판에는 부적합합니다

초무쿤 · Answer

자연키 대리키 를 한반 찾아보세요

쿠잉 · Answer

2) 회원,등급, 기타 테이블멤버 테이블 및 등급(grade) 테이블 또는 포인트 테이블등은 각각 만들어서 사용하면 될것 같습니다.회원(멤버) 테이블ID(auto_increment) | 계정명(영어 또는 이메일주소) | 이름(한글) | 이메일주소 | 회사명(회사코드) | 가입일 | 활성화여부 | 삭제여부(탈퇴여부) 위와 같은 형태로 회사명 또는 회사코드로 구분하면 됩니다.로그인시에 ID / PW / 회사코드(숫자 또는 영문+숫자) 를 입력하여 로그인 하는 형태도 있을수 있고계정명@회사도메인.com / PW 로 로그인 할 수 있고요향후 서비스가 커지면 모듈 별로 분리하게 되는게 보통임으로 Account 또는 멤버 성격의 도메인 테이블을 함께 분리하여 회원DB 라는 별도의 DB를 분리하고, 게시판은 게시판DB 라고 별도로 분리하는 것을 계획해볼수도 있고요이것도 향후이지 처음에는 DB 한곳에서 같이 사용하시면 됩니다.

집킨 · Answer

처음부터 하위 테이블들에서 fk만 잘 걸어놨으면 innoDB의 auto increment 를 pk로 쓰더라도 문제가 없겠죠

장독깨기 · Answer

고객사 별로 ID를 1번 부터 부여하려니 고민이 많은거죠.굳이 1번 부터 할 이유가 별로 없어 보이긴 합니다만, (전 1번 부터 부여하지 않습니다.)굳이 1번 부터 부여하겠다면,테이블 하나에 번호를 다 관리한다든지, MAX 값을 읽는 다든지 하는건,락이 자주 걸리니, 이런 방식은 별로 안 좋아 보입니다.시퀀스를 사용하는게 좋은데요, 좀 알아보니,마리아 DB 는 시퀀스를 지원하는거 같은데요, mysql 에는 지원을 하지 않네요.결론. 굳이 하겠다면, 3번으로 하면 될 거 같습니다. :)

DB 테이블 설계, 다중 auto increment

6개의 답변

기술 목록