이현도 [hotsword27] 11-04-21 14:18

 

  정확한 값을 말하기는 어렵고 1에 한없이 가깝습니다.

이현도 [hotsword27] 11-04-21 14:19

 

  대충 두들겨보니 50만명만 있어도 중복될 확률이 50%정도 되네요.

김진성 [iq240asia] 11-04-21 14:36

 

  현재 DB서버가 버틸수 있는 정도로 30만쿠폰을 생성후 중복확인을 해보니 0개 중복이라도 결과가 나왔습니다....

이현도 [hotsword27] 11-04-21 14:39

 

  30만건의 경우 지금 만든 액셀으로 구해보니까, 중복이 나올 확률이 22.5%네요

이현도 [hotsword27] 11-04-21 14:45

 

  쿠폰의 가지수를 a, 사람수를 n이라고 하고, 중복될 확률을 계산해보겠습니다.

임의의 두명을 뽑았을때, 그 두사람의 쿠폰번호가 다를 확률은 (a-1) / a 가 됩니다.
n명이 뽑은 쿠폰이 모두 중복되지않는 확률을 먼저 계산해보죠.
임의로 두명을 뽑은 모든 경우에 대해 그 두사람간의 쿠폰번호가 달라야하는것인데
n명 중에 임의로 두명을 뽑을 수 있는 경우의 수는 n(n-1)/2 입니다.
즉, { (a-1)/a } ^ { (n(n-1)/2 } 가 '모두 중복되지않는 확률'이 되겠고,
'중복이 하나라도 있을 확률'은 1에서 빼면 되니
1 -  { (a-1)/a } ^ { (n(n-1)/2 } 가 됩니다.

일단 여기에  a와 n을 원하시는 조건대로 26^3 * 10^7 와 60억을 넣으면
1에 한없이 가까운 숫자가 나오는지라 도움이 안되실꺼구요.
지금 원하시는 값을 계산하려면 저기서 사람수나 쿠폰갯수를 조정해보세요.

23명만 있어도 그중에 생일이 같은 사람이 있을 확률이
50%를 넘는다는 얘기아시나요?
언뜻 이해하기 어렵지만 유명한 얘기죠. 그것과 똑같은 문제입니다.
저 식에 사람수에 23, 쿠폰수에 365를 넣어서 계산해봐도 50.05%정도가 나오는걸 확인하실수 있으실꺼에요.

이현도 [hotsword27] 11-04-21 14:58

 

  e로 설명하는게 더 좋겠네요.
e의 정의랑 제가 위에 적은 식을 비교해 보면
'쿠폰수의 두배 = 사람수의 제곱'이 성립할때 중복없을 확률이 약 1/e정도 됩니다. 대략 37%죠. 있을 확률은 약 63%가 되려나요.

김진성님께서 말씀해주신 쿠폰수는 26^3 * 10^7 이니 약 1758억(1.8*10^11) 정도인데
사람수가 60억이면, '쿠폰수의 두배 = 사람수의 제곱'이랑은 약간 거리가 먼 값이죠.
60억 기준으로 중복이 있을 확률이 63%정도 될 경우가 되려면
쿠폰수가 1.8*10^19 정도는 되어야합니다.
중복이 있을 확률을 낮추려면 당연히 쿠폰수가 좀 더 많이 있어야겠구요.

정정목 [blue940] 11-04-23 22:05

 

  1년이 4569억일이라고 했을 때 60억명의 사람 중 생일이 같은 사람이 있을 확률.

김지원 [tnqkrzmfla] 11-05-04 10:27

 

  물론 다 아시겠지만
프로그램 적으로 쿠폰번호를 발급할때 중복이 되면 안되는 항목이라면 pk로 지정해 놓으시고 그렇게 되면 pk의 유ㄴㅣㅋ조건에 위배 될시 반드시 튕기게 되어 있습니다.

튕겨져 나온 오류문을 사용자에게 노출하지 않고 프로그램에서 따로 처리하여 다시 생성하도록 로직을 돌리면 중복이 안될것입니다.

수학적 지식이 없어서 위의 경우의 수가 몇이 나올지는 모르겠지만 60억개가 되지 않는다면 만들 수 있는 경우의 수를 모두 만든 후에 더이상 발급 할 수 없다는 메세지를 토해내며 멈추게 한다면 중복이 될 확률은 0입니다.

어떤 쿠폰인지는 모르겠으나 60억 인구가 발급받을 확률이 얼마나 될지가 먼저 생각해봐야겠습니다.

또한 세계인구가 60억이라고 가정한다고 하더라도 첫번째 발급받은 사람이 마지막 60억번째 사람이 발급 받을때까지 쿠폰을 사용하지 않는다면 쿠폰의 존재 의미가 없는것이겠죠.

그렇기에 사용된 쿠폰은 일정 기간 동안 폐기처리 했다가 다시 재활용 하는것도 생각해 봐야겠습니다.

재활용이 문제가 된다면 그냥 폐기처리만 해도 되겠네요.

여기서 문제가 되는것은 만약 위의 가정을 다 무시하고 60억개의 쿠폰이 미사용 상태로 발급이 되었을때입니다.

과연 쿠폰을 사용하려고 번호를 입력했을때 그 쿠폰이 유효한 것인지 검사를 하는 조회를 하는 시간은 얼마가 걸릴것인가.

인덱스를 잘 준다고 해도 감당이 될지 의문입니다.

전체 자리를 랜덤으로 발급하는것보다는 관리 차원에서 앞의 영문과 뒷자리 숫자는 발급 나라 혹은 지역, 발급 일자 등으로 관리 하는것이 나을 것 같습니다.

예를 들어 한국에서 발급된 쿠폰 앞자리는 항상 a로 시작한다고 프로그램 적으로 정의를 해두고 테이블도 한국 용으로 a로 시작하는 쿠폰 번호만 입력해두고 프로그래밍 한다면 접속지역이 한국일때 a의 테이블에서 검사를 하거나.

2010년에 발급되는 쿠폰의 두번째 자리를 0으로 지정해 두고 세번째 영문을 발급 월에 해당하는 알파벳을 넣어 둔다면 관리가 더 수월할 것 같습니다.

그리고 여담입니다만 대소문자를 구분하면 경우의 수가 더 늘어 날것입니다.
여담에 여담입니다만 관리가 필요 없다면 0~9 or A - Z or a - z 로 전체 항목을 체운다면 더 늘어나겠네요. 만약 이렇게 한다면 단어나 짧은 문장이 만들어질 수도 있겠네요. ' -' 세계적인 쿠폰이라면 그런 레어 쿠폰이 비싸게 팔릴 수도 있겠습니다. ㅇㅁ ㅇ