GUID ชนกันได้หรือไม่

128

ฉันกำลังทำงานกับฐานข้อมูลใน SQL Server 2000 ที่ใช้ GUID สำหรับผู้ใช้แต่ละคนที่ใช้แอพที่เชื่อมโยงกับมัน อย่างใดผู้ใช้สองคนลงเอยด้วย GUID เดียวกัน ฉันรู้ว่าไมโครซอฟท์ใช้อัลกอริทึมในการสร้าง GUID แบบสุ่มที่มีโอกาสในการก่อให้เกิดคอลลาเจนต่ำมาก แต่การชนยังคงเป็นไปได้หรือไม่

sql-server guid

— Jason Baker
แหล่งที่มา

11

ทุกคนบอกว่าไม่ผิดฉันได้รวบรวม 1 UniqueIdentifier ที่มีชุดข้อมูลที่น้อยกว่าครึ่งล้านระเบียน MSSQL 2008 R2

— Behrooz

2

@Behrooz Yikes มันเป็นไปไม่ได้ด้วยการขอบคุณวันเกิดเพื่อนที่ขัดแย้งกันของเรา แต่มันก็ยังโชคร้ายอย่างไม่น่าเชื่อกับ v4 GUID แบบสุ่มอย่างสมบูรณ์ บางทีคุณกำลังใช้กลยุทธ์การสร้าง GUID ที่อ่อนแอลง?

— Craig Ringer

6

@Behrooz ว้าว นั่นเป็นโชคที่น่าตกใจ

— Craig Ringer

6

@Behrooz นี่อาจเป็นตัวเลขสุ่มหลอกที่มีข้อบกพร่องที่ใช้ใน MSSQL (ฉันจะไม่แปลกใจถ้าพวกเขามีเมล็ดพันธุ์แบบ 32 บิตในเครื่องกำเนิดของพวกเขาหรือไม่ชอบคุณภาพของซอฟต์แวร์ของพวกเขา) คณิตศาสตร์ไม่ได้โกหก ความเป็นไปได้นี้มีขนาดเล็กมากเพื่อให้คุณสามารถเป็น 99.9999999999 (และมากถึง 9 หลังจาก)% ที่เครื่องกำเนิดไฟฟ้า guid MSSQL เสีย (หรืออาจเป็นเครื่องกำเนิดไฟฟ้าแบบหลอกเทียมที่ใช้ในการสร้าง GUID) หรือคุณทำผิดพลาด

— Alex

2

รักในช่วงเวลาที่แน่นอนทั้งคำถามและคำตอบที่เลือกมี 128 คะแนน เหตุบังเอิญ? 🤔

— Caio Cunha

127

โดยทั่วไปไม่มี ฉันคิดว่ามีคนเข้าไปยุ่งกับฐานข้อมูลของคุณ ทั้งนี้ขึ้นอยู่กับรุ่น GUID ที่คุณใช้ค่านั้นเป็นค่าเฉพาะ (สำหรับสิ่งต่าง ๆ เช่นรุ่น 1 GUID) หรือทั้งไม่ซ้ำกันและไม่แน่นอน (สำหรับสิ่งต่าง ๆ เช่นรุ่น 4 GUID) การติดตั้ง SQL Server ของฟังก์ชัน NEWID () ของพวกเขาดูเหมือนจะใช้ตัวเลขสุ่ม 128 บิตดังนั้นคุณจะไม่ได้รับการชนกัน

สำหรับโอกาส 1% ของการชนคุณจะต้องสร้างGUID ประมาณ2,600,000,000,000,000,000 GUID

— Tom Ritter
แหล่งที่มา

3

นั่นคือสิ่งที่ฉันคิด แต่ฉันแค่ต้องการให้แน่ใจว่าฉันไม่สามารถแยกแยะได้ คุณไม่มีทางรู้ว่าบั๊กแปลก ๆ แบบไหนที่จะปรากฏในซอฟต์แวร์อายุ 8 ปี :)

— Jason Baker

6

จริงๆแล้วมันไม่จริงอีกต่อไป มันเป็นความจริงสำหรับ v1 GUID แต่ไม่ใช่สำหรับ v4 ปัจจุบัน ดูen.wikipedia.org/wiki/Globally_Unique_Identifier#Algorithmสำหรับข้อมูลเพิ่มเติม

— Greg Beech

97

ลงคะแนนเพราะในหลักการ (ในรูปแบบดิบที่สุด) คุณผิดที่จะพูดว่า "ไม่" สำหรับคำถาม "มีการปะทะกันของ GUID หรือไม่" เป็นไปได้มาก โอกาสที่จะเล็ก แต่ก็เป็นไปได้ ฉันเกลียดที่จะฟังเสียงอึกทึกครึกโครม แต่ SO นั้นเกี่ยวกับความรัดกุมและแม่นยำ

13

ป้อน "แก้ปัญหา [1-exp [- (n ^ 2 / (2 * 2 ^ 128))]> 0.01, n]" ลงใน wolfram alpha เพื่อรับผล 1% ... โปรดทราบว่าในขณะที่ตัวเลขนี้มีขนาดใหญ่ บริบทของแอปพลิเคชั่นเดียวแน่นอนว่ามันไม่ใหญ่สำหรับคนทั้งโลก หากคอมพิวเตอร์ทุกเครื่องบนโลกจะสร้าง GUID จริงขึ้นมาพวกเขาจะทำให้เกิดการชนกันที่มีความน่าจะเป็น 1% ภายในเวลาประมาณหนึ่งวินาทีโดยสมมติว่าพวกเขาสามารถสร้าง GUID ได้ในแต่ละวินาที (ซึ่งอาจเป็นจริงในปัจจุบัน) ดังนั้นถ้าคุณใช้ GUID สำหรับ ID ฐานข้อมูลของคุณแล้วมันจะไม่ซ้ำกัน GUID สำหรับการคำนวณทุกอย่างที่ทำบนโลกจะปะทะกันทันที

— thesaint

11

การบอกว่า 'ไม่' เป็นไปไม่ได้และจากนั้นบอกว่ามีโอกาส 1% ที่จะได้รับการปะทะเมื่อมีจำนวนหนึ่งถูกสร้างขึ้นเป็นความขัดแย้งโดยตรง การตอบสนองที่ถูกต้องควรในเชิงทฤษฎี - ใช่การชนกันอาจเกิดขึ้นแบบสุ่ม อย่างไรก็ตามโอกาสของการชนนั้นมีขนาดเล็กกว่าดาวเคราะห์น้อยที่กระทบโลกการกระเด้งออกจากโลกและกระดอนจากดวงจันทร์เพื่อชนโลกเป็นครั้งที่สองในชั่วโมงถัดไป

— Baaleos

112

โดยทั่วไปพวกเขาเป็นไปไม่ได้! มีโอกาสเป็นต่ำ astronomically

แต่ ... ฉันเป็นเพียงคนเดียวในโลกที่ฉันรู้จักนั่นมีการจัดระเบียบ GUID ครั้งเดียว (อ๋อ!)

และฉันก็แน่ใจและไม่ผิด

มันเกิดขึ้นได้อย่างไรในแอปพลิเคชั่นขนาดเล็กที่ทำงานบน Pocket PC เมื่อสิ้นสุดการดำเนินการคำสั่งที่มี GUID ที่สร้างขึ้นจะต้องถูกใช้ คำสั่งหลังจากที่ถูกดำเนินการบนเซิร์ฟเวอร์นั้นจะถูกเก็บไว้ในตารางคำสั่งบนเซิร์ฟเวอร์พร้อมกับวันที่ดำเนินการ วันหนึ่งเมื่อฉันทำการดีบั๊กฉันได้ออกคำสั่งโมดูล (พร้อมกับ GUID ที่สร้างขึ้นใหม่) และไม่มีอะไรเกิดขึ้น ฉันทำมันอีกครั้ง (พร้อม guid เดียวกันเนื่องจาก guid ถูกสร้างขึ้นเพียงครั้งเดียวที่จุดเริ่มต้นของการดำเนินการ) และอีกครั้งและไม่มีอะไรเลยในที่สุดพยายามค้นหาว่าทำไมคำสั่งไม่ทำงานฉันจึงตรวจสอบตารางคำสั่ง และ GUID เดียวกับที่ปัจจุบันถูกแทรก 3 สัปดาห์ที่ผ่านมา ไม่เชื่อสิ่งนี้ฉันคืนค่าฐานข้อมูลจากการสำรองข้อมูล 2 สัปดาห์และ guid อยู่ที่นั่น ตรวจสอบรหัส guid ใหม่ถูกสร้างขึ้นใหม่ไม่ต้องสงสัยเลยว่ามัน

แก้ไข: มีปัจจัยบางอย่างที่อาจเพิ่มโอกาสในการเกิดขึ้นอย่างมากแอปพลิเคชันนี้ทำงานบน PocketPC emulator และตัวจำลองมีคุณสมบัติบันทึกสถานะซึ่งหมายความว่าทุกครั้งที่สถานะถูกกู้คืนเวลาท้องถิ่นจะถูกกู้คืนด้วย และ guid จะขึ้นอยู่กับตัวจับเวลาภายใน .... นอกจากนี้ขั้นตอนวิธีการสร้าง guid สำหรับเฟรมเวิร์กขนาดกะทัดรัดอาจจะน้อยกว่าตัวอย่างเช่น COM one ...

— Pop Catalin
แหล่งที่มา

38

upvoted บันทึกสถานะ & เล่นซ้ำจะสร้าง guids ซ้ำกันจริงๆ

— Joshua

35

สิ่งที่เกิดขึ้นคือสิ่งนี้คือการนำ GUID ไปปฏิบัติ ทฤษฎีอัตราต่อรองอยู่ในระดับต่ำมาก แต่ใน Pocket PC ?? ใครจะบอกว่าพวกเขาไม่ได้ใช้ทางลัดที่ชนเหล่านั้นเข้าสู่หมวดหมู่ "ไม่น่าจะเป็นไปได้ แต่เป็นไปได้"

— Dave Dopson

9

เพียงเพราะบางสิ่งมีความเป็นไปได้ต่ำมากที่จะเกิดขึ้นไม่ได้หมายความว่ามันจะไม่เกิดขึ้น

— Renan

3

ดังที่ฉันได้กล่าวไว้ข้างต้นโอกาสที่มีขนาดเล็กมากขึ้นเรื่อย ๆ จนสามารถสันนิษฐานได้ว่าคุณทำผิดหรือ MSSQL ใช้ PRNG ที่มีข้อบกพร่อง ( en.wikipedia.org/wiki/Pseudorandom_number_generator ) เช่นมีโอกาสที่ PRNG นี้จะ initalized ด้วยเมล็ดขนาดเล็ก PRNGs ที่มีข้อบกพร่องไม่ได้หายาก (ดูschneier.com/paper-prngs.html ) - ตัวอย่างเช่นพบข้อบกพร่องหนึ่งรายการใน Android SDK - android-developers.blogspot.com/2013/08/… + usenix.org/conference/woot14 / workshop-program / presentation / …

— Alex

2

@Alex ข้อผิดพลาดคือ "บันทึกสถานะและกู้คืน" จาก Emulator ซึ่งเรียกคืนรูปภาพจำลองทั้งหมดรวมถึงนาฬิกาจำลอง ดังนั้นหลังจากการดำเนินการคืนค่าหลายพันครั้งในหนึ่งปีจะมีการสร้าง guid collision หนึ่งครั้ง คุณพูดถูกผิด!

— Pop Catalin

34

มีความเป็นไปได้ในทางทฤษฎี แต่มีตัวเลขที่เป็นไปได้ 3.4E38 หากคุณสร้าง GUID หลายสิบล้านครั้งในหนึ่งปีโอกาสที่จะมีหนึ่งซ้ำเป็น 0.00000000006 ( ที่มา )

หากผู้ใช้สองคนจบลงด้วย GUID เดียวกันฉันจะเดิมพันว่ามีข้อผิดพลาดในโปรแกรมซึ่งทำให้ข้อมูลถูกคัดลอกหรือแชร์

— เบ็นฮอฟสไตน์
แหล่งที่มา

"แต่ด้วยตัวเลขที่เป็นไปได้ 3.4E38" - ไม่ GUID สองตัวที่สร้างขึ้นเกือบจะพร้อมกันในเครื่องเดียวกันจะจบลงด้วย GUID ที่คล้ายกัน

— Kirk Strauser

4

ซึ่งจะขึ้นอยู่กับวิธีสร้าง GUID และการใช้งานบางอย่างที่อิงตามเวลา CPU หรือมิลลิวินาที (หวังว่า) จะมีผลดีกว่าการคำนวณใด ๆ ก็ตามจากสอง GUID ที่สร้างจากมิลลิวินาทีจะมีความแตกต่างกันอย่างมาก

— Dalin Seivewright

4

ด้วยตัวประมวลผลมากกว่า 1 ตัวบนเครื่องหาก guid อิงตามเวลาและที่อยู่ mac ดังนั้นแต่ละคอร์สามารถออก guid เดียวกันได้ในเวลาเดียวกัน

— AndyM

12

ฉันค่อนข้างมั่นใจว่าการใช้งาน GUID ที่เหมาะสมจะไม่เกิดขึ้น

— Guillaume86

1

@MatthewLock บุคคลที่ผิดธรรมดาวันเกิดครอบคลุมในแหล่งที่มา ตรวจสอบลิงค์

— Zero3

21

ก่อนอื่นให้ดูโอกาสของการชนกันของ GUID สองตัว มันไม่ได้เป็นคำตอบอื่น ๆ ที่ระบุไว้ 1 ใน 2 ^ 128 (10 ^ 38) เพราะวันเกิดความขัดแย้งซึ่งหมายความว่ามีโอกาส 50% ของสอง GUID ที่ชนกันน่าจะเป็น 1 ใน 2 ^ 64 (10 ^ 19) ซึ่งเล็กกว่ามาก อย่างไรก็ตามนี่ยังคงเป็นจำนวนที่มากและความน่าจะเป็นของการชนที่สมมติว่าคุณกำลังใช้ GUID ที่มีเหตุผลอยู่ในระดับต่ำ

โปรดทราบว่า GUID นั้นไม่มีการประทับเวลาหรือที่อยู่ MAC เนื่องจากหลาย ๆ คนดูเหมือนจะเชื่อเช่นกัน นี่เป็นความจริงสำหรับ v1 GUID แต่ตอนนี้ใช้ v4 GUID ซึ่งเป็นตัวเลขสุ่มหลอกซึ่งหมายความว่าความเป็นไปได้ของการปะทะจะสูงขึ้นเนื่องจากไม่ได้เป็นเวลาและเครื่องจักรอีกต่อไป

ดังนั้นคำตอบคือใช่การชนกันเป็นไปได้ แต่พวกเขาไม่น่าเป็นไปได้สูง

แก้ไข: แก้ไขเพื่อพูด 2 ^ 64

— เกร็กบีช
แหล่งที่มา

2

ในขณะที่ฉันเห็นด้วยกับข้อเท็จจริงทั้งหมดของคุณโปรดระวังคณิตศาสตร์ของคุณ ในการบอกว่าคุณมีโอกาส 1 ใน 10 ^ 19 ของการปะทะกันของ GUID สองอันขึ้นอยู่กับจำนวน GUID ที่อยู่ในชุด สำหรับโอกาสนั้นคุณต้องการ ~ 2 ^ 32 GUID ดังนั้นในสถานการณ์จริงเกือบทั้งหมดราคาที่ต่ำกว่ามาก

— DocMax

1

คุณมีการพิมพ์ผิดของซึ่งผมคิดว่าควรจะเป็น1 in 10^64 (10^19) 1 in 2^64 (10^19)ฉันยังสับสนอย่างมากว่าคุณคิดว่าวันเกิดที่ผิดธรรมดาใช้กับตัวเลขเพียง 2 ตัวได้อย่างไร ผมถือว่าคุณมองไปที่en.wikipedia.org/wiki/Birthday_paradox ตารางแสดงจำนวน guids ที่คุณต้องการสำหรับความน่าจะเป็นที่ซ้ำกัน จากตารางดังกล่าวน่าจะเป็น 1 ใน 10 ^ 18 ต้องใช้ 2.6 * 10 ^ 10 guids ไม่ได้มีอะไรใกล้เคียงกับ GUID เพียงสองตัว

— Tony Lee

จุดหนึ่ง - v1 guids ยังคงใช้งานได้อย่างกว้างขวางและพึ่งพาที่อยู่ MAC โดยเฉพาะในฐานข้อมูลเนื่องจากมีลักษณะที่ต้องการ ดู UuidCreateSequential และมันของ SQL Server เสื้อคลุม NewSequentialID ( msdn.microsoft.com/en-us/library/windows/desktop/... )

— EBarr

18

โอกาสของการสุ่ม GUID สองครั้งที่ชนกัน (~ 1 ใน 10 ^ 38) ต่ำกว่าโอกาสที่จะไม่ตรวจจับแพ็คเก็ต TCP / IP ที่เสียหาย (~ 1 ใน 10 ^ 10) http://wwwse.inf.tu-dresden.de/data/courses/SE1/SE1-2004-lec12.pdfหน้า 11 นี่เป็นความจริงเช่นกันของดิสก์ไดรฟ์ไดรฟ์ซีดี ฯลฯ ...

GUID นั้นมีเอกลักษณ์ทางสถิติและข้อมูลที่คุณอ่านจากฐานข้อมูลนั้นถูกต้องทางสถิติเท่านั้น

— โทนี่ลี
แหล่งที่มา

คุณแน่ใจหรือว่าฉันไม่สามารถป้องกันเครือข่ายของฉันดังนั้นแพ็คเก็ตน้อยกว่า 1 ใน 10 ^ 28 เสียหาย?

— Joshua

13

ฉันจะถือว่ามีดโกนของ Occamเป็นแนวทางที่ดีในกรณีนี้ เป็นไปได้ยากอย่างไม่น่าเชื่อที่คุณจะมีการปะทะกันของ GUID เป็นไปได้มากว่าคุณมีข้อบกพร่องหรือมีคนมายุ่งกับข้อมูลของคุณ

— เจสันแจ็คสัน
แหล่งที่มา

1

ที่จริงแล้วในสถานการณ์เช่นนี้ใบมีดโกนของ Occam ไม่ใช่ไกด์ที่ดีเลย! มีดโกนของ Occam กล่าวว่ากรณีที่มีสมมติฐานน้อยที่สุดน่าจะถูกต้องมากที่สุด ในสถานการณ์นี้กรณีของการปะทะกันของ GUID นั้นง่ายกว่ามาก แต่มีดโกนของ Occam ไม่ได้ใช้กับสถานการณ์เช่นนี้ซึ่งเรารู้แล้วว่ากรณีหนึ่งในนั้นไม่น่าเป็นไปได้

— lockstock

11

ดูบทความUnique Identifier ทั่วโลกของ Wikipedia มีหลายวิธีในการสร้าง GUID เห็นได้ชัดว่าวิธีเก่า (?) ใช้ที่อยู่ Mac เวลาประทับลงไปยังหน่วยที่สั้นมากและตัวนับที่ไม่ซ้ำกัน (เพื่อจัดการรุ่นที่รวดเร็วบนคอมพิวเตอร์เครื่องเดียวกัน) ดังนั้นการทำซ้ำจึงเป็นไปไม่ได้เกือบ แต่ GUID เหล่านี้ลดลงเพราะสามารถใช้เพื่อติดตามผู้ใช้ ...

ฉันไม่แน่ใจเกี่ยวกับอัลกอริทึมใหม่ที่ใช้โดย Microsoft (บทความบอกว่าสามารถคาดเดาลำดับของ GUID ได้ดูเหมือนว่าพวกเขาจะไม่ใช้การประทับเวลาอีกต่อไปหรือไม่บทความของ Microsoft ที่ลิงก์ไว้ด้านบนพูดอย่างอื่น ... )

ตอนนี้ GUID ได้รับการออกแบบมาอย่างพิถีพิถันเพื่อให้มีความเป็นเอกลักษณ์ทั่วโลกดังนั้นฉันจะเสี่ยงว่ามันเป็นไปไม่ได้หรือมีโอกาสน้อยมาก ฉันจะดูที่อื่น

— PhiLho
แหล่งที่มา

6

Eric โพสต์ 1

— Nat

4

Eric post 2

— Nat

4

Eric โพสต์ 3

— Nat

9

เครื่อง Win95 สองเครื่องที่มีการ์ดอีเทอร์เน็ตที่มีที่อยู่ MAC ที่ซ้ำกันจะออก GUIDS ที่ซ้ำกันภายใต้เงื่อนไขที่มีการควบคุมอย่างเข้มงวดโดยเฉพาะอย่างยิ่งถ้าเช่นไฟดับในอาคารและเครื่องทั้งสองก็บูตในเวลาเดียวกัน

— โจชัว
แหล่งที่มา

เป็นเรื่องปกติที่เครื่องที่แตกต่างกันสองเครื่องจะมีที่อยู่ MAC ของอีเทอร์เน็ตเดียวกันหรือไม่

— เดฟ Lucre

@DaveLucre: ไม่ แต่มีการบันทึกเหตุการณ์

— Joshua

ฉันสงสัยจริงๆว่ามันเกิดขึ้นได้อย่างไร เป็นไปได้มากขึ้นกับ VM ที่สุ่มสร้าง MAC สำหรับแต่ละ NIC หรือไม่ ฉันไม่เคยได้ยินเกี่ยวกับ NIC ทางกายภาพที่ผลิตด้วย MAC ที่ซ้ำกัน! ชนิดของการโยนประแจขนาดใหญ่ในงานถ้าเป็นไปได้!

— เดฟ Lucre

ว้าว! ขอบคุณสำหรับลิงค์ @Joshua! ช่างน่ากลัวขนาดนี้!

— เดฟ Lucre

@DaveLucre ฉันใช้ USB NIC ราคาถูกมากบางตัวซึ่งทั้งหมดนั้นผลิตด้วย MAC เดียวกัน แต่แน่นอนว่าไม่มีส่วนเกี่ยวข้องกับคณิตศาสตร์ของการสุ่มและทุกอย่างเกี่ยวกับความขี้เกียจของผู้ผลิต

— rudolfbyker

5

ฉันจะใส่คำนำหน้าด้วย "ฉันไม่ใช่คนที่มีเครือข่ายดังนั้นฉันอาจทำประโยคที่ไม่ต่อเนื่องกันอย่างสมบูรณ์"

เมื่อฉันทำงานที่ Illinois State University เรามีเดสก์ท็อปของ Dell สองเครื่องสั่งซื้อในเวลาที่ต่างกัน เราใส่อันแรกในเครือข่าย แต่เมื่อเราพยายามใส่อันที่สองในเครือข่ายเราเริ่มได้รับข้อผิดพลาดที่บ้า หลังจากการแก้ไขปัญหามากก็พบว่าทั้งสองเครื่องกำลังผลิต GUID เดียวกัน (ฉันไม่แน่ใจว่าจะทำอะไร แต่มันทำให้พวกเขาทั้งคู่ใช้เครือข่ายไม่ได้) Dell เปลี่ยนทั้งสองเครื่องเป็นข้อบกพร่อง

— จอห์นคราฟท์
แหล่งที่มา

3

มันเป็น GUID โดยเฉพาะ มันมีบางอย่างเกี่ยวกับ GUID ที่สร้างโดยเครื่องเมื่อพวกเขาเข้าร่วมเครือข่าย Dell ใช้เวลาหลายสัปดาห์ในการเปลี่ยนเครื่องเพราะพวกเขาบอกว่ามันเป็นไปไม่ได้ที่ GUID จะเหมือนกัน เราสามารถสร้างปัญหาขึ้นมาได้ Dell นำเครื่องกลับมาและสามารถสร้างผลลัพธ์เดียวกันบนเครือข่ายของพวกเขา พวกเขาลงเอยด้วยการเปลี่ยนทั้งสองเครื่อง อย่างที่ฉันพูดฉันไม่ใช่คนเครือข่าย แต่ฉันจำได้โดยเฉพาะว่าเป็นปัญหากับ GUID

— จอห์นคราฟท์

5

ฉันรู้ว่าคนชอบคำตอบที่รู้สึกดีที่ GUID นั้นมีมนต์ขลังและรับประกันว่าจะไม่เหมือนใคร แต่ในความเป็นจริง GUID ส่วนใหญ่เป็นเพียงตัวเลขสุ่ม 121 บิต (เจ็ดบิตเสียการจัดรูปแบบ) หากคุณรู้สึกไม่สะดวกใจที่จะใช้หมายเลขสุ่มขนาดใหญ่คุณควรรู้สึกไม่สบายเมื่อใช้ GUID

— Rick Yorgason
แหล่งที่มา

11

ขอแนะนำให้คุณอย่าใช้เครือข่าย หรือคอมพิวเตอร์ พาริตี้บิตสามารถทำได้มากเท่านั้น!

— Rushyo

คุณเข้าใจผิด มีสองสิ่งที่ฉันพยายามจะพูดในโพสต์นี้: 1) หากคุณต้องการตัวเลขสุ่มขนาดใหญ่ให้ใช้ตัวเลขสุ่มขนาดใหญ่ การใช้ GUID เป็นตัวเลขสุ่มขนาดใหญ่ทำให้เข้าใจผิดโดยไม่จำเป็น (2)

— Rick Yorgason

4

ซึ่งฉันรู้อย่างเต็มที่ คุณระบุว่า "หากคุณไม่สะดวกที่จะใช้หมายเลขสุ่มขนาดใหญ่ แต่ GUID นั้นมีเอกลักษณ์ที่คุณจะพบว่าทุกอย่างในคอมพิวเตอร์นั้นมีความสุ่มมากขึ้นแม้กระทั่งการดำเนินการที่คุณได้รับก็ตาม มีโอกาสมากขึ้นที่หน่วยความจำที่ผิดปกติจะทำลายคอลัมน์ข้อมูลประจำตัวของคุณมากกว่าจะเกิดการปะทะกันของ GUID (จริง) คุณไม่ควรรู้สึก 'อึดอัด' กับพวกเขา หากพวกเขาไม่เหมาะสำหรับสถานการณ์ก็ดี แต่พวกเขาไม่ต้องการความระมัดระวังเป็นพิเศษ

— Rushyo

3

ฉันเดาว่านี่จะไม่มีที่ไหนเลย แต่สิ่งที่ผู้คนพยายามอธิบายให้คุณทราบคือการตรวจจับข้อผิดพลาด mecanisms ในฮาร์ดแวร์ทั่วไปเช่นการ์ดเครือข่ายหรือฮาร์ดไดรฟ์ใช้อัลกอริทึมที่มีโอกาสมากกว่าที่จะไม่พบข้อผิดพลาด คุณพึ่งพาสิ่งเหล่านี้คุณสามารถพึ่งพา GUID ได้เช่นกัน

— Guillaume86

1

@ ริคขึ้นอยู่กับว่าหมายเลขของคุณใหญ่แค่ไหน แน่นอนว่าไม่ใช่ด้วยไบต์ 4 int หรือ 8 ไบต์ใหญ่ GUID = 16 ไบต์ดังนั้นคุณต้องมีการติดตั้งจำนวน 16 ไบต์ที่กำหนดเองเพื่อให้ได้ชุดค่าผสมที่เป็นไปได้ 2 ^ 128 ดังนั้นโดยทั่วไปถ้าพูดโดยใช้ 'ปกติ' int หรือตัวเลขสุ่มขนาดใหญ่โอกาสที่จะเกิดการชนกับ GUID นั้นต่ำกว่า

— Wim Hollebrandse

3

รหัสที่ใช้สร้าง GUID มีข้อบกพร่องหรือไม่ ใช่แน่นอนมันสามารถ แต่คำตอบนั้นเหมือนกันกับข้อผิดพลาดของคอมไพเลอร์ - โค้ดของคุณคือคำสั่งที่มีขนาดใหญ่น่าจะเป็นบั๊กกี้ดังนั้นให้ดูที่นั่นก่อน

— มาร์คแรนซัม
แหล่งที่มา

2

แน่นอนมันเป็นไปได้ .... อาจเป็นไปได้? ไม่น่าเป็นไปได้ แต่มันเป็นไปได้

โปรดจำไว้ว่าเครื่องเดียวกันกำลังสร้าง GUID ทุกตัว (เซิร์ฟเวอร์) ดังนั้น "สุ่ม" จำนวนมากที่ขึ้นอยู่กับข้อมูลเฉพาะของเครื่องจะหายไป

— FlySwat
แหล่งที่มา

1

เพียงยิ้มให้ลองสคริปต์ต่อไปนี้ ... (ใช้ได้กับ SQL 2005, ไม่แน่ใจเกี่ยวกับ 2000)

declare @table table
(
    column1 uniqueidentifier default (newid()),
    column2 int,
    column3 datetime default (getdate())
)

declare @counter int

set @counter = 1

while @counter <= 10000
begin
    insert into @table (column2) values (@counter)
    set @counter = @counter + 1
end

select * from @table

select * from @table t1 join @table t2 on t1.column1 = t2.column1 and t1.column2 != t2.column2

การเรียกใช้ซ้ำ ๆ (ใช้เวลาน้อยกว่าหนึ่งวินาที) จะสร้างช่วงที่ค่อนข้างกว้างจากตัวเลือกแรกแม้จะมีช่องว่างช่วงเวลาสั้น ๆ อย่างมาก จนถึงตอนนี้ตัวเลือกที่สองยังไม่ได้ผลิตอะไรเลย

— GalacticCowboy
แหล่งที่มา

1

คุณต้องมีศูนย์อีก 15 ตัวที่ส่วนท้ายของเคาน์เตอร์เพื่อให้มีโอกาส 50% ในการทำซ้ำ แต่เพื่อประโยชน์ของ Pete อย่าทำ!

— Jim Birchall

0

เป็นไปไม่ได้หากผู้ใช้มีเครื่องที่แตกต่างกันกับการ์ดเครือข่ายและแม้ว่าจะไม่เป็นเช่นนั้นก็ยังคงเป็นความเสี่ยงทางทฤษฎีเกือบทั้งหมด

โดยส่วนตัวฉันจะดูที่อื่นเพราะเป็นข้อผิดพลาดมากกว่าการปะทะ GUID ...

ให้แน่นอนว่าคุณไม่ต้องสับบิต GUID เพื่อทำให้สั้นลง

— ริชาร์ดแฮร์ริสัน
แหล่งที่มา

GUID จะถูกสร้างขึ้นบนเซิร์ฟเวอร์ดังนั้นการ์ดเครือข่ายของผู้ใช้จะไม่เข้ามาเล่น

— Tom Ritter

0

แน่นอนว่าเป็นไปได้และอาจเป็นไปได้ ไม่ใช่ว่า GUID แต่ละรายการจะอยู่ในพื้นที่สุ่มที่เป็นไปได้ ในกรณีที่สองเธรดพยายามสร้างหนึ่งพร้อมกันยกเว้นฟังก์ชัน GUID แบบรวมศูนย์ด้วยเซมาฟอร์รอบ ๆ พวกเขาสามารถจบด้วยค่าเดียวกัน

— Kirk Strauser
แหล่งที่มา

0

ไม่น่าเป็นไปได้สูงที่คุณจะพบเจอกับการชนของ GUID หากคุณสร้างสิ่งเหล่านี้ผ่านNEWID()ฟังก์ชั่นเช่นเดียวกับใน SQL Server (แน่นอนว่าเป็นไปได้ สิ่งหนึ่งที่พวกเขาไม่ได้ชี้ให้เห็นก็คือมีแนวโน้มว่าคุณจะพบเจอกับการชนถ้าคุณสร้าง GUID ใน JavaScript บนเบราว์เซอร์ บางครั้งไม่เพียง แต่จะมีปัญหาใน RNG ในเบราว์เซอร์ที่แตกต่างกัน แต่ฉันยังพบปัญหาที่สไปเดอร์ของ Google ดูเหมือนจะแคชผลลัพธ์ของฟังก์ชั่นแบบนั้น

ดูคำตอบต่าง ๆ ที่นี่สำหรับรายละเอียดเพิ่มเติม:

มีการชนกันเมื่อสร้าง UUID ใน JavaScript หรือไม่

— เคนสมิ ธ
แหล่งที่มา