Database에 ID를 적용하는 것은 보통 Integer로 한다. 이유는 ID로 하기에 Data가 작고 보통 AutoIncrement를 지원하기 때문에 간편하기 때문이다.
IntegerID는 하나를 사용하는데는 문제가 없는데 관계가 맺어진 DB에서는 약간 문제인게 관계가 맺어진 DB는 ID를 바로 찾을 수 없기 때문이다.
예를 들어 직장인 Table과 회사Table이 있다고 했을때 직장인+회사 Table이 같이 존재한다고 치자. 그 Table에는 아마 직급이라던가, 포트폴리오등 이 직장인이 회사에서 한 행동에 대한 Data가 있을 수 있다. 그런데 만일 직장인+회사 Table을 가져오려고 한다면 보통 요청에서 가질 수 있는 것은 직장인 ID와 회사 ID뿐이다. 따라서 직장인+회사 Table의 ID를 얻어오려면 Query가 필요하게 되는데 이 점이 맘에 들지 않는다는 점이다.
만일 직장인+회사 Table의 ID를 합치는 방식을 사용한다고 했을때 Integer + Integer가 Unique를 보장하지 않는다. 그렇다고하면 생각할 수 있는 것은 String + String이다. 하지만 일반적으로 알려진 UUID는 36Byte로 4Byte인 Integer에 비하면 사실 말도 안된다.
그래서 nanoID를 쓰기로 결정하였다. 8 Length로 하면 시간당 1000개의 ID가 만들어진다고 가정할때 99일 걸린다고 한다. 사실 시간당 1000개가 만들어질 정도면 대박난거라서.. 분명히 중복으로 에러가 나는 경우가 있을텐데 에러처리하고 될때까지 ID발급하면 된다! 그럼 관계테이블은 16Length로 합의를 볼 수 있다.
NanoID 충돌 계산기
Nano ID CC
NanoID Github
GitHub - ai/nanoid: A tiny (130 bytes), secure, URL-friendly, unique string ID generator for JavaScriptA tiny (130 bytes), secure, URL-friendly, unique string ID generator for JavaScript - GitHub - ai/nanoid: A tiny (130 bytes), secure, URL-friendly, unique string ID generator for JavaScriptGitHubai
