باستخدام المعرّف الفريد العمومي (GUID) كمفتاح أساسي

I generally use auto increment IDs as Primary Keys in databases. I am trying to learn the benefits of using GUIDs. I have read this article: https://betterexplained.com/articles/the-quick-guide-to-guids/

أدرك أن يتم استخدام هذه GUIDs لتحديد الكائنات على مستوى التطبيق. هل يتم تخزينها أيضًا كمفتاح أساسي على مستوى قاعدة البيانات. على سبيل المثال ، لنفترض أن لدي الفصل الدراسي التالي:

public class Person
{
public GUID ID;
public string Name;
..

//Person Methods follow
}

قل أردت إنشاء شخص جديد في الذاكرة ثم أدخل الشخص في قاعدة بيانات. هل يمكنني القيام بهذا فقط:

Person p1 = new Person();
p1.ID=GUID.NewGUID();
PersonRepository.Insert(p1);

لنفترض أن لديّ قاعدة بيانات تحتوي على الملايين والملايين من الصفوف باستخدام المعرّف الفريد العمومي (GUID) باعتباره المفتاح الأساسي. هل سيكون هذا دائمًا فريدًا؟ هل أنا حتى فهم GUIDs بشكل صحيح؟

قرأت هذا المقال في وقت سابق: http://enterprisecraftsmanship.com/2014/11/15/CQS مع قاعدة بيانات ولدت المعرفات/. أنه يخلط لي قليلا كما يظهر أن يوصي وسيلة سعيدة بين المعرفات الفريدة العمومية وصحيحة كما المفاتيح الأساسية.

تعديل 11/06/18

لقد جئت لأعتقد أن Guids أكثر ملاءمة من النواتج لمتطلباتي. أستخدم CQRS أكثر هذه الأيام وتناسب المعرفات الفريدة العمومية بشكل أكثر.

ألاحظ أن بعض المطورين يقومون بتكوين GUID كسلسل في نموذج المجال مثل e. هنا: https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.Domain/AggregatesModel/BuyerAggregate/Buyer.cs - في هذه الحالة: IdentityGuid هو GUID تم تصميمه كـ سلسلة. هل هناك أي سبب للقيام بهذا غير ما هو مذكور هنا: استخدم كائن قيمة مخصصة أو Guid كمعرّف كيان في نظام موزع؟ . هل من "العادي" وضع GUID كسلسلة أو يجب أن أقوم بنمذجته كـ GUID في الطراز وقاعدة البيانات؟

31
لقد جئت إلى الاعتقاد أن Guids هي أكثر ملاءمة من النمل لمتطلبات بلدي. أنا أقول GUID هو الملاذ الأخير (و int لهذه المسألة). الفهرسة لا معنى لها ، وغامضة ، في أحسن الأحوال ، في الاستعلامات. OTOH ، المفاتيح المركبة هي DSL-ish المستخدمة ، السياقية ، الوصفية ، المرنة ، والمهمة للأداء. يمكن استخدام الاستعلامات على مجموعة فرعية من PK المركبة. أحذر من إنشاء PKs في حد ذاته - حيث لا يوجد ما يبرره. لا يوجد شيء خطأ في الفهرسة حسب الحاجة على الجداول غير المستخدمة. تقوم PKs بشكل جوهري بتوصيل بنية البيانات والعلاقات والمتطلبات.
وأضاف المؤلف jbu, مصدر
النظام الذي أعمل به في الوقت الحالي يستخدم UUIDs. الخاصية الجميلة هي أن المعرف يعرّف سجلاً بشكل فريد ، على عكس المعرف التسلسلي الذي يعرّف سجل في هذا الجدول.
وأضاف المؤلف Bakhtiyor, مصدر
@ w0051977 لم يفعلوا ذلك ، ولكن يمكن أن تساعد - لقد رأيت (أنظمة مشفرة بشكل سيئ) التي تم فيها استخدام RoleId بشكل غير صحيح كـ UserRoleId - وفي مطور بيئات عملت حتى ، لأن معرف 1 عمل في كلتا الحالتين. مع UUIDs ستكون معرفات مختلفة.
وأضاف المؤلف Bakhtiyor, مصدر
نسخة محتملة من UUID vs Integer
وأضاف المؤلف gnat, مصدر
راجع أيضًا: collisions UUID
وأضاف المؤلف gnat, مصدر
وأضاف المؤلف Euphoric, مصدر
راجع أيضًا dba.stackexchange.com/questions/54690/&hellip؛ ، بالإضافة إلى الكثير من الأسئلة الأخرى - تم طرح هذا الموضوع ، و أجاب و جادل في كثير من الأحيان.
وأضاف المؤلف Arash, مصدر
غير مضمون أن تكون فريدة من نوعها ، على الرغم من أنه من غير المرجح أن ترى تصادمًا. stackoverflow.com/questions/1155008/how-unique- هو-UUID/و hellip؛
وأضاف المؤلف icirellik, مصدر
Justin ، لماذا السجلات تحتاج إلى أن تكون فريدة عبر جداول متعددة؟
وأضاف المؤلف w0051977, مصدر

10 إجابة

المعرفات الفريدة العمومية (GUIDs) حسب تعريف "معرفات فريدة عمومية". هناك مفهوم مشابه لكنه مختلف قليلاً في لغة Java يسمى UUIDs "Universal Unique Unique Identifiers". الأسماء قابلة للتبادل لجميع الاستخدام العملي.

تعتبر المعرفات الفريدة العمومية (GUIDs) أساسية بالنسبة إلى كيفية قيام Microsoft بتخطيط تجميع قواعد البيانات للعمل ، وإذا كنت بحاجة إلى دمج البيانات من مصادر متصلة أحيانًا ، فإنها تساعد بالفعل في منع تضارب البيانات.

بعض الحقائق GUID Pro:

  • تمنع GUID من التصادمات الأساسية
  • تساعد المخططات GUID في دمج البيانات بين الشبكات والآلات وما إلى ذلك.
  • لدى SQL Server دعمًا لـ GUID شبه المتتالية للمساعدة في تقليل تجزئة الفهرس ( ref ، some caveats)

بعض القبح مع المعرفات الفريدة العمومية

  • حجمها كبير ، 16 بايت لكل منها
  • إنها خارج نطاق الترتيب ، لذا لا يمكنك التصنيف على رقم الهوية وتأمل في الحصول على طلب الإدراج كما يمكنك في معرفات الزيادة التلقائية
  • أكثر تعقيدًا للعمل معها ، خاصةً على مجموعات البيانات الصغيرة (مثل البحث عن الجداول)
  • تطبيق GUID الجديد أكثر قوة على SQL Server مما هو عليه في مكتبة C# (يمكنك الحصول على GUID المتسلسلة من SQL Server ، في C# يكون عشوائيًا)

ستجعل المعرفات الفريدة العمومية (GUIDs) الفهارس الخاصة بك أكبر ، لذا ستكون تكلفة مساحة القرص لفهرسة عمود أعلى. سوف GUIDs عشوائية تجزئة الفهارس الخاصة بك.

إذا كنت تعلم أنك لن تقوم بمزامنة البيانات من شبكات مختلفة ، يمكن للمعرفات الفريدة العمومية (GUIDs) حمل مقدار حمل أكبر من قيمتها.

إذا كنت بحاجة إلى استيعاب بيانات من عملاء متصلين أحيانًا ، فيمكن أن تكون أكثر قوة لمنع التصادمات الأساسية من الاعتماد على إعداد نطاقات التسلسل لهؤلاء العملاء.

39
وأضاف
أنا جعلت هذا المجتمع WIKI ، وإزالة العبارات الأكثر إثارة للجدل. يكون في ذلك وجعلها الإجابة الأكثر الصحيح. أحصل على الشعور أنني كنت على المسار الصحيح ولكن كان في عداد المفقودين على بضع نقاط رئيسية.
وأضاف المؤلف tim_yates, مصدر
كما فعلت أولاً. شكرًا على التعليقات ، لقد تعلمت بعض الأشياء.
وأضاف المؤلف tim_yates, مصدر
هناك أيضًا هذه المعلومات التي يمكن أن تساعد أيضًا: blog.codinghorror.com/primary -keys-ids-versus-guids (يمكن أن يكون لديك GUIDs تسلسلي في SQL Server متسلسلة لكل جهاز قيد التشغيل)
وأضاف المؤلف tim_yates, مصدر
إليك بعض المعلومات: blogs.msdn.microsoft .com/sqlserverfaq/2010/05/27/& hellip؛ سأعترف أن بعض معلوماتي المتعلقة بـ GUID و SQL Server clustering قديمة. تتغير بعض الأشياء وتبقى بعض الأشياء كما هي (على سبيل المثال يدعم SQL Server التجميع الفشل للأعوام الماضية فقط)
وأضاف المؤلف tim_yates, مصدر
JimmyJames ، بما أن العلامة كانت لـ SQL Server ، فقد صممت الإجابة لذلك. لم يتم إنشاء Oracle أبدًا استنادًا إلى المعرفات الفريدة العمومية (GUID) أو UUIDs ، لذا فأنا لم أفاجأ بتجربتك.
وأضاف المؤلف tim_yates, مصدر
"إنهم خارج نطاق النظام ، لذا لا يمكنك أن تقوم بالفرز على الهوية ، وتأمل في الحصول على طلب الإدراج كما يمكنك في معرفات الزيادة التلقائية" بصراحة ، أنا لست مرتاحًا بالاعتماد على ذلك مع معرفات عادية أيضًا. على الرغم من أنه من الممكن في حالة حافة متطرفة للحصول على معرف أقل أن يلتزم القرص في وقت لاحق ، فما استقاموا لكم فاستقيموا بدلا الاعتماد على بيانات فرز مفيدة ، مثل الطابع الزمني الإدراج. يجب التعامل مع معرفات مثل عناوين الذاكرة - كل شيء واحد ، ولكن القيمة نفسها لا معنى لها. استخدمها لقوائم ألعاب على الأكثر. خاصةً إذا كان لديك تحميل مجمّع ، لا يتم ضمان أمر الإدراج.
وأضاف المؤلف Hao Sun, مصدر
MaxVernon "ليس الأمثل" هو التخفيض الهائل.
وأضاف المؤلف Andy, مصدر
"يحتوي SQL Server على تحسينات للتعامل مع المعرفات الفريدة العمومية (GUIDs) لذا لا يجب أن يؤثر ذلك على أداء الاستعلام بشكل كبير." -1 ليس تقريبا الأمثل بما فيه الكفاية. أنا أعمل مع DB حيث جميع PKs هي أدلة ، واحدة من الأسباب الرئيسية لضعف الأداء.
وأضاف المؤلف Andy, مصدر
"يحتوي SQL Server على تحسينات للتعامل مع المعرفات الفريدة العمومية (GUID) حتى لا يؤثر ذلك على أداء الاستعلام بشكل كبير. " غير صحيح. يفترض هذا البيان أن أنواع البيانات الأخرى غير محسّنة. تحتوي خوادم قواعد البيانات أيضًا على تحسينات للتعامل مع قيم int بسيطة ، على سبيل المثال. تكون GUIDs/UUID أبطأ بكثير من استخدام قيمة int 4 بايت. لن تكون 16 بايت أبداً بالسرعة التي تصل إلى 4 بايت - خاصة على جهاز يتعامل مع 4 أو 8 بايت على الأكثر.
وأضاف المؤلف user192127, مصدر
CortAmmon وفقًا لـ Wikipedia و RFC 4122 ، فهي مترادفة. كان P. Leach من Microsoft أحد مبدعي RFC. أعتقد أنه منذ إنشاء RFC ، فإن الاثنين متشابهان. من RFC: "UUIDs (Universal Unique Identifier) ​​، والمعروف أيضًا باسم GUID (معرّف فريد عمومي)." أعتقد أنه من المفيد أيضًا ملاحظة أنه لم يتم إنشاء المعرفات الفريدة العمومية (GUIDs) بواسطة MS. لقد أنشأوا للتو اسمًا جديدًا لتقنية تم تبنيها من مكان آخر.
وأضاف المؤلف JimmyJames, مصدر
MartinSmith أعتقد أن النقطة هي أن المعرف الداخلي للصف في DB هو GUID. إنه نفس الشيء بالنسبة لـ Oracle ، لكنني غير متأكد من أن الحالة تستخدمه بالضرورة في كل عملية بحث.
وأضاف المؤلف JimmyJames, مصدر
MartinSmith هذا خارج خبرتي ولكن هناك شيء في صفحة UUID wikipedia ذو صلة.
وأضاف المؤلف JimmyJames, مصدر
MartinSmith هذه معلومات مفيدة لكنني لست من المعجبين بهذا ، كما هو موضح في التعليقات المختلفة هنا.
وأضاف المؤلف JimmyJames, مصدر
ما أفهمه هو أن GUIDs مترادفة مع UUIDs. UUID هو الاسم القياسي. GUID هو ما صاغته Microsoft قبل RFC 4122 .
وأضاف المؤلف JimmyJames, مصدر
نعم ، أنا أقترح فقط فكرة جيدة لفهم جيدًا للمفاضلات التي قد تكون متورطة في هذا الأمر. لقد ذكرت القليل منها ، لا أعرف إذا كان هذا شاملًا. في حالتنا كنا نستخدم معرفات الصف "الأصلي" مثل PK. لذلك فأنا أوافق على أن أوراكل لا تتعامل مع هذا الأمر بشكل جيد ، إلا أنه "تم بناؤه" بالفعل حول هذا الموضوع. إنه 128 بت ، على أقل تقدير ، في عام 2017 ، فإنك تجبر DB على استخدام أكثر من سجل واحد لكل مفتاح.
وأضاف المؤلف JimmyJames, مصدر
+1 وأنا أوصي قراءة غرامة المطبوعة على الكيفية التي يعالج بها ديسيبل هذه. فعلنا هذا في أوراكل وذهبت سيئة للغاية. كان لابد من تعديل الاستعلامات بطريقة غامضة من أجل الوصول إلى المؤشر. والشيء الآخر المثير للمشكلة (IIRC) هو أن المعرف الفريد العمومي (GUID) الذي تم إنشاؤه على نفس الجهاز في نفس الوقت يميل إلى أن يكون هو نفسه في البداية والنهاية ولكنه مختلف في الوسط لذا تحتاج إلى إستراتيجية فهرسة خاصة للتعامل مع هذا الموقف خاصة مجموعة كبيرة جدا المحتملة.
وأضاف المؤلف JimmyJames, مصدر
MaxVernon هو السبب في أن البعض يشير إلى الجمع بين الجمع بين مجموعات + المعرف الفريد العمومي؟
وأضاف المؤلف Mark Maruska, مصدر
@ ypercubeᵀᴹ - أفترض أن هذه هي إحدى الطرق "للتغلب" على مشكلة تجزئة الجدول. على الرغم من أن ذلك سيكون مجرد تداول قضية واحدة لآخر. أكوام ليست جيدة إلا إذا كان بإمكانك TRUNCATE TABLE بشكل متكرر.
وأضاف المؤلف Geocode.Farm Staff, مصدر
إذا قالت السيدة تريب إن هذا صحيح ، فإنه هو صحيح.
وأضاف المؤلف Geocode.Farm Staff, مصدر
أنا أيضا مهتمة بأي اختلاف هناك بين المعرفات الفريدة العمومية (GUID) و UUIDs. يقترح إجابات كهذه بشكل مترادف ، لكن Stack Exchange بعيد كل البعد عن مصدر نهائي /ducks
وأضاف المؤلف Cort Ammon, مصدر
أصبحت GUID و UUID مترادفتان. إن محاولة التعامل معها بشكل مختلف سيؤدي إلى إرباك الأشخاص في الطريق.
وأضاف المؤلف icirellik, مصدر

هل سيكون هذا دائمًا فريدًا؟

Always? no, not always; it's a finite sequence of bits.

لنفترض أن لديّ قاعدة بيانات تحتوي على الملايين والملايين من الصفوف باستخدام المعرّف الفريد العمومي (GUID) باعتباره المفتاح الأساسي.

الملايين والملايين ، أنت على الأرجح آمنة. يصبح الملايين من الملايين ، و احتمال حدوث تصادم كبيرًا. هناك أخبار جيدة ، على الرغم من: لقد نفدت مساحة القرص بالفعل في الوقت الذي يحدث.

هل يمكنني فعل هذا؟

يمكنك؛ انها ليست فكرة جيدة كليا. لا ينبغي أن يكون نموذج نطاقك عادةً هو توليد أرقام عشوائية ؛ يجب أن تكون مدخلات في النموذج الخاص بك.

أبعد من ذلك ، عندما تتعامل مع شبكة غير موثوقة ، حيث قد تحصل على رسائل مكررة ، فإن الحتمية التي تنشئها UUID ستحميك من وجود كيانات مكررة. ولكن إذا عيّنت رقمًا عشوائيًا جديدًا لكل منها ، فسيكون عليك القيام بمزيد من العمل لتحديد الازدواجية.

See the description of name-based uuid in RFC 4122

هل من "العادي" وضع المخططات GUID كسلسلة أو هل يجب تصميم نماذج لها كـ GUID في النموذج وقاعدة البيانات؟

لا أعتقد أنه مهم جدا. بالنسبة لمعظم نموذج المجال الخاص بك ، فهو معرف ؛ والاستعلام الوحيد الذي تطلبه هو ما إذا كان هو نفس رقم التعريف الآخر أم لا. لن يبحث نموذج نطاقك عادةً في تمثيل الذاكرة لمعرّف.

إذا كان المعرف الفريد العمومي (GUID) متاحًا كنوع "بدائي" في إعداد لا أجري لنطاقك ، فسوف استخدمه ؛ يسمح للسياق الداعم باختيار التحسينات المناسبة التي قد تكون متاحة.

لكن ما يجب أن تعرفه هو أن تمثيل المعرف ، سواء في الذاكرة أو في التخزين ، هو قرار تقوم بإجرائه في التنفيذ ، وبالتالي يجب أن تتخذ خطوات لضمان أن تكون طباعة الرمز إلى جانب ذلك القرار صغير - راجع Parnas 1972 .

25
وأضاف
مليون مليون = 2 ^ 40. وهذا يجعل 2 ^ 79 زوج من الاصطدامات المحتملة. المعرف الفريد العمومي لديه 2 ^ 128 بت ، وبالتالي فإن فرصة واحدة في 2 ^ 49. من الأرجح أن يكون لديك خطأ يعيد استخدام نفس المعرّف الفريد العمومي (GUID) لسجلين ، أو يعتقد خطأً أن هناك تصادمًا لا يوجد به.
وأضاف المؤلف gnasher729, مصدر
في الواقع ، القدرة على إعادة حساب UUID/GUID استناداً إلى بيانات أخرى هي مساعدة هائلة ، خاصةً للكشف عن التكرارات. أنا مرة واحدة بنيت نظام معالجة الرسائل التي تخزن الرسائل ودفعتها من خلال خط أنابيب المعالجة. أنا خلقت تجزئة للرسالة واستخدامها كمفتاح أساسي في جميع أنحاء النظام. هذا فقط ، في حد ذاته ، حل لي الكثير من القضايا لتحديد الرسالة عندما كان علينا أن نطاق خارج.
وأضاف المؤلف Newtopian, مصدر
أشعر أن مفهوم " UUID الحتمية " ضروري (انظر Data Vault 2)
وأضاف المؤلف peterd, مصدر
ربما يحتاج هؤلاء المطورين إلى تحسين عمليات التداول الخاصة بهم بشكل مختلف.
وأضاف المؤلف VoiceOfUnreason, مصدر
شكر. فقط حتى أنا واضح. يقترح الإجابة على GUID في طراز المجال (C #) و معرف فريد (بدلاً من قول varchar) في قاعدة البيانات (SQL Server). ألاحظ أن الأمر مختلف عما هو موجود هنا: github.com/dotnet-architecture/eShopOnContainers/blob/dev/sr&zwnj؛ c/& hellip؛
وأضاف المؤلف w0051977, مصدر
سأعود من خلال أسئلتي التاريخية. قبل أن أقبل هل يمكنك إلقاء نظرة على تعديلي؟
وأضاف المؤلف w0051977, مصدر
لإجراء 1+ "لقد نفدت مساحة القرص بالفعل بحلول الوقت الذي يحدث."
وأضاف المؤلف w0051977, مصدر

من المحتمل جدًا أن يكون المعرف الفريد العمومي (GUID) أو UUID فريدة بسبب كيفية توليدها وتوفر طريقة آمنة لضمان التفرد دون الحاجة إلى الاتصال بسلطة مركزية.

فوائد المعرفات الفريدة العمومية (GUID) كمفتاح أساسي:

  • يمكنك نسخ البيانات بين الأجزاء المختلفة من مجموعة ، ولا داعي للقلق بشأن تصادم PK. </لى>
  • تتيح لك معرفة مفتاحك الأساسي قبل إدراج أي سجلات.
  • يبسط منطق المعاملة لإدخال السجلات الفرعية.
  • لا يمكن تخمينها بسهولة.

في المثال الذي قدمته:

Person p1 = new Person();
p1.ID = GUID.NewGUID();
PersonRepository.Insert(p1);

يمكن أن يؤدي تحديد المعرف الفريد العمومي (GUID) قبل وقت الإدراج إلى حفظ رحلة ذهاب وإياب إلى قاعدة البيانات عند إدراج سجلات فرعية متتالية وتتيح لك الالتزام بها في المعاملة نفسها.

Person p2 = new Person();
p2.ParentID = p1.ID
PersonRepository.Insert(p2);

يضر إلى GUIDs كمفتاح أساسي:

  • حجمها 16 بايتًا كبيرًا مما يعني أنها ستستهلك مساحة أكبر حيث تتم إضافة الفهارس والمفاتيح الخارجية.
  • لا يتم ترتيبها جيدًا لأنها أرقام عشوائية في الأساس.
  • استخدام الفهرس سيء جدًا ، جدًا ،
  • الكثير من الأوراق المتحركة.
  • من الصعب تذكرها.
  • من الصعب التعبير عن الكلام.
  • يمكن أن تجعل من الصعب قراءة عنوان URL.

إذا لم يكن التطبيق الخاص بك بحاجة إلى المشاركة أو التجميع ، فمن الأفضل الالتزام بأنواع بيانات أصغر وأبسط مثل int أو bigint.

تحتوي العديد من قواعد البيانات على تطبيقات داخلية خاصة بها تحاول تخفيف مشكلات التخزين التي تسببها GUID و SQL Server حتى تحتوي على وظيفة newsequentialid للمساعدة في ترتيب UUID مما يسمح باستخدام أفضل للفهارس ولديهم بشكل عام خصائص أداء أفضل.

بالإضافة إلى ذلك ، من منظور المختبر أو المستخدم أو المطور الذي يعمل مع التطبيق ، فإن استخدام معرف عبر المعرف الفريد العمومي (GUID) سيحسن التواصل بشكل كبير. تخيل الحاجة إلى قراءة GUID عبر الهاتف.

في النهاية ، ما لم يكن تجميع عناوين URL أو تشويشها على نطاق واسع شرطًا ، فمن البرجماتي التمسك بالمعرفات المتزايدة تلقائيًا.

10
وأضاف
التناقض Freemirabilos Fon ، باستخدام نوع من خوارزمية Hi-Lo محلية الخيط سيكون IMHO حلاً أبسطًا ولا يزال بإمكانك الحصول على معرفات أصغر وأكثر تسلسلًا في الغالب.
وأضاف المؤلف David Nehme, مصدر
mirabilos أيضا ، أنا لا أوصي باستخدام مفاتيح 128 بت في أوراكل. شاهد تعليقي على إجابة بيرين. يمكن أن يكون الأداء حول هذه الأنواع من PKs في Oracle أمراً مرعباً إذا لم تقم بتقديم مخصصات خاصة له.
وأضاف المؤلف JimmyJames, مصدر
mirabilos سأكون مهتمة بفهم كيف/عندما لا يكون ذلك قابلا للحل عن طريق زيادة حجم كتلة التسلسل.
وأضاف المؤلف JimmyJames, مصدر
ربما اسأت الفهم. افترضت "يمكنهم جعل URL أكثر صعوبة في القراءة". ضمنيًا أنه سيتم استخدامها هناك. لست متأكداً من أنني أوافق على أن استخدام المفتاح في الـ URI هو بالضرورة مشكلة دائمًا ولكن يمكن أن يكون ذلك بالتأكيد.
وأضاف المؤلف JimmyJames, مصدر
mirabilos لكي أكون واضحًا ، عندما أقول مروعة ، انتهى بنا الأمر إلى وجود إدخالات تستغرق دقيقة لكل صف. بدأ الخروج من "موافق" ولكن بعد أن كان هناك 10 آلاف من الصفوف ، ذهب سريعًا جانبياً. إذا لم يكن الأمر واضحًا ، فإن 10 آلاف من الصفوف عبارة عن جدول صغير جدًا.
وأضاف المؤلف JimmyJames, مصدر
هناك أمر واحد يجب أخذه في الاعتبار هو أنه بناءً على نوع UUID ، فإنها تحتوي على معلومات من المحتمل أن تكون تستخدم لتحديد الجهاز الذي يتم إنشاؤه عليه. قد يكون الاصطدام العشوائي الصافي أكثر احتمالاً للاصطدام بدون إنتروبيا كافية. يجب اعتبار ذلك قبل الاستخدام في URI.
وأضاف المؤلف JimmyJames, مصدر
السبب الرئيسي لاستخدامها هو أن وجود المعرف الفريد العمومي (GUID) كمفتاح فهرس متفاوت المسافات سيؤدي إلى تجزئة ثقيلة ، حيث لن يتم استخدام المعرف الفريد العمومي المتسلسل. يأتي ذلك مع بعض مزايا الأداء بالإضافة إلى بعض المخاطر الأمنية ، مثل إمكانية التنبؤ بها.
وأضاف المؤلف icirellik, مصدر
متفق عليه ، على الرغم من أنه يجب على المرء ألا يعرض مفتاحه الأساسي في عنوان URL. يجب استخدام بعض الطرق الأكثر ملاءمة لضمان عدم وجود بيانات آمنة تتسرب إلى النظام الخارجي
وأضاف المؤلف icirellik, مصدر
إذا كنت تستخدم newsequentialid ثم عليك أن تذهب إلى ديسيبل للحصول على معرف (مثل مع الهوية int) ، أليس كذلك؟ ما هي الفائدة هنا.
وأضاف المؤلف w0051977, مصدر
هناك حالة استخدام واحدة أخرى: قواعد بيانات OLTP المدرجة الثقيلة التي يكون فيها تأمين التسلسل هو عنق الزجاجة. وفقًا لصديقي في Oracle DBA ، هذا ليس نادرًا كما يبدو ، فأنت لا تحتاج حتى إلى نطاق واسع أو مجموعات كبيرة لذلك. • في النهاية ، ضع ثقلًا على الإيجابيات والسلبيات (ولا تربك إيجابيات وسلبيات UUIDs بإيجابيات/سلبيات ليست خاصة بـ UUID كما تفعل بعض الملصقات) و قياس .
وأضاف المؤلف mirabilos, مصدر
يمكنك "مساعدة" التجزئة عن طريق إنشاء قيمة "guid-like-like" على جانب العميل (في C# على سبيل المثال). ينشئ UuidCreateSequential GUIDs تسلسلي مثل هذه: 19F287B4-8830-11D9-8BFC-000CF1ADC5B7 19F287B5-8830-11D9-8BFC-000CF1ADC5B7 19F287B6-8830-11D9-8BFC-000CF1ADC5B7 19F287B7-8830-11D9-8BFC-000CF1ADC5B7 19F287B8-8830-11D9-8BFC -000CF1ADC5B7 راجع pinvoke.net/default.aspx/rpcrt4.UuidCreateSequential
وأضاف المؤلف granadaCoder, مصدر

أود أن أقول لا ، لا تستخدم المعرفات الفريدة العمومية (GUIDs) كمفاتيح أساسية. أنا في الواقع التعامل مع مثل هذا DB الآن ، وأنها واحدة من الأسباب الرئيسية لمشاكل الأداء.

تضيف البايتات الإضافية 12 بسرعة ؛ تذكر ، سيكون معظم PKs FKs في جداول أخرى ، وثلاثة FKs فقط في جدول لديك الآن 48 بايت إضافية لكل صف. الذي يضيف في الجدول والفهارس. كما يضيف في القرص I/O. تلك 12 بايت إضافية تحتاج إلى قراءة وكتابة.

وإذا كنت لا تستخدم أدلة متسلسلة ويتم تجميع ملفات PK (وهو ما يحدث افتراضيًا) ، فسيتعين على SQL من وقت لآخر نقل صفحات كاملة من البيانات للضغط أكثر في "موضع" صحيح. بالنسبة لقاعدة بيانات عالية المعاملات مع الكثير من الإدخالات والتحديثات والحذف ، فإن الأمور تتعطل بسرعة.

إذا كنت بحاجة إلى نوع من المعرف الفريد للمزامنة أو شيء ما ، فقم بإضافة عمود تعريف. فقط لا تجعلها PK.

4
وأضاف

أدرك أنه يتم استخدام هذه المعرفات الفريدة العمومية (GUIDs) لتحديد الكائنات على مستوى التطبيق. هل يتم تخزينها أيضًا كمفتاح أساسي على مستوى قاعدة البيانات.

هذا هو المكان الذي يجب أن تتوقف فيه ، هناك ، وإعادة التفكير.

يجب ألا يكون مفتاحك الأساسي لقاعدة البيانات له معنى عمل. يجب أن يكون بلا معنى من حيث التعريف.

لذلك ، أضف المعرّف الفريد العمومي (GUID) ليكون مفتاح عملك ، ومفتاحًا أساسيًا عاديًا (عادةً طويلة int) كمفتاح أساسي لقاعدة البيانات. يمكنك دائمًا وضع فهرس فريد على GUID لضمان التفرد.

هذا هو الحديث عن نظرية قواعد البيانات بالطبع ، لكنها ممارسة جيدة كذلك. لقد تعاملت مع قواعد البيانات حيث كان للمفاتيح الأساسية معنى عمل (كان أحد العملاء يعتقد أنه يحفظ بعض موارد قواعد البيانات من خلال استخدامها كأعداد الموظفين ، وأرقام العملاء ، إلخ. على سبيل المثال) ويؤدي دائمًا إلى حدوث مشكلات.

2
وأضاف
icirellik المفتاح الأساسي مخصص للاستخدام الداخلي بواسطة قاعدة البيانات ، لربط السجلات الأصلية والطفولة وما شابه ذلك. لا يُقصد به استخدام منطق التطبيق ، بل تستخدم معرّفات العمل لهذا ، مثل رقم منتج أو اسم.
وأضاف المؤلف jwenting, مصدر
كيف يختلف هذا عن الاستعلام عن طبقة التطبيق باستخدام مفتاح أساسي صحيح؟ عند هذه النقطة ، يتم استخدامه أيضًا لتحديد الكائنات في طبقة التطبيق. تحتاج إلى طريقة لتحديد الكائنات في قاعدة بيانات من طبقة التطبيق.
وأضاف المؤلف icirellik, مصدر

استخدم دائمًا قاعدة البيانات التي يتم إنشاؤها ، أو زيادة المفاتيح الأساسية تلقائيًا (PKs).

لماذا استخدام الزيادة التلقائية بدلاً من GUID/UUID؟

  • لا تمنع GUID (UUID) التصادمات الأساسية لأنها ليست فريدة ولا توجد طريقة لجعلها فريدة لأنها يتم إنشاؤها من مصادر متعددة.
  • لا تساعد المعرفات الفريدة العمومية (GUID) في الدمج لأنها تزيد من عملية دمج تستغرق وقتًا طويلاً بالفعل مع أعمدة PK و FK طويلة جدًا وغير صحيحة تستغرق وقتًا طويلاً في المعالجة. تذكر أنه بالنسبة لمعظم PKs ، سيكون هناك جدول واحد على الأقل مع مفتاحين على الأقل من نفس الحجم: هو PK الخاص به و FK مرة أخرى إلى الجدول الأول. يجب أن يتم حل كل شيء في الدمج.

ولكن كيف إذن للتعامل مع القطع ، والعناقيد ، وما إلى ذلك؟

  • إنشاء مجموعات PK متعددة الأعمدة مكونة من أعمدة منفصلة تحدد كل جزء/مجموعة/قاعدة بيانات/أيًا كانت تدير مفاتيح الزيادة التلقائية الخاصة بها. على سبيل المثال ...

قد يكون PK 3-العمود لجدول متفاوت المسافات ...

 DB | SH | KEY     |
----|----|---------|
 01 | 01 | 1234567 |

لكن ماذا عن...؟

  • رحلات متعددة إلى قاعدة البيانات - لا تحتاج معظم التطبيقات إلى تحديد السجل الذي يتم إنشاؤه بشكل فريد حتى يتم إدخاله في قاعدة البيانات حيث أن هذا الخيط/الجلسة/أيًا كان يعمل فقط في وقت واحد. إذا كان التطبيق يحتاج بالفعل إلى هذه الإمكانية ، فاستخدم تطبيقًا مؤقتًا

    مؤقت لم يتم إرساله إلى قاعدة البيانات . دع قاعدة البيانات ثم وضع PK زيادة تلقائية الخاصة بها على الصف عندما يتم إدراجها. ستستخدم الإدخالات PK المؤقت ، في حين أن التحديثات والحذف سوف تستخدم PK الدائم المعين من قبل قاعدة البيانات.

  • الأداء - تستطيع أجهزة الكمبيوتر معالجة الأعداد الصحيحة البسيطة بسرعة أكبر من أي شيء آخر نظرًا للنطاق الأكبر حجمًا إذا كانت القيم الممكنة لكل عنصر في المعرف الفريد العمومي (37) مقابل عدد صحيح (10). تذكر أيضًا أنه يجب أولاً تحويل كل حرف في المعرّف الفريد العمومي (GUID) إلى رقم ليتم معالجته بواسطة وحدة المعالجة المركزية.

Common Misuses of Primary Keys PKs have only one purpose... to absolutely uniquely identify a row in a table. Anything else is an all-too-common misuse.

الكشف عن السجلات المفقودة

  • Missing records cannot be detected by looking at the PKs. Bless QA for at least attempting to ensure data quality. However, they and programmer's lack of understanding of how keys in modern database systems are assigned often leads them to the misbelief that a missing number in an auto-incrementing PK means missing data. It does not because...
  • For performance, database systems allocate blocks of numbers in 'sequences'(batches, ranges) to minimize trips to the actual database in storage. The size of these sequences of numbers is often under the control of the DBA but may not be tunable on a per-table basis.
  • The key takeaway is... unused numbers from these sequences are never returned to the database so there are always gaps in the PK numbers.
  • Why would there be unused numbers you ask? Because a variety of database maintenance actions may cause sequences to be abandoned. These are things like restarts, bulk reloads of tables, some types of restoration from backups and some other operations.

فرز

  • فرز by PK is very error-prone since most people will think it lists the rows in the order they were created and that that corresponds to clock time. Mostly, but not necessarilly.
  • Database engines are optimized for maximum performance and that may mean delaying insert of the results of a long-running complicated transaction in order to insert short simple ones, "out-of-turn" so to speak.
2
وأضاف
RibaldEddie - بقدر ما تم تصميم قاعدة البيانات للسماح ... على الاطلاق. عمليات الحذف سهلة. عندما يحدث السيناريو الخاص بك ، أود أن أعتبر أنه علة أن تكون ثابتة في البرنامج ثم قم بحذف أي من الصف. والحالة الأكثر شيوعًا على الرغم من ذلك هي وجود سجلين لنفس الشيء مع بيانات مختلفة قليلاً حتى يتم دمجهما. إذا كان العمود فارغًا في سجل واحد ولديه قيمة في الآخر ، فإن الخيار واضح ويمكن أن يكون آليًا. في كثير من الأحيان يمكن استخدام datetimestamp للتحكيم في الدمج الآلي. تتطلب بعض التكرارات قيام شخص بإنهاء والتحقق من الدمج بناءً على قواعد العمل.
وأضاف المؤلف yaplik, مصدر
لقد أضفت الكثير إلى الإجابة على هذا المنوال. كانت الإجابة الأصلية غير كاملة بسبب تطبيق Android SE الذي أقوم بتعليقه. أعتقد أن إعادة كتابة رئيسية للتطبيق قيد التطوير.
وأضاف المؤلف yaplik, مصدر
لذا في رأيك ، سيكون من المقبول أن يحتوي أي جدول على أي عدد من الصفوف التي تم حفظها متطابقة لمفتاحها الأساسي المتزايد تلقائيًا؟
وأضاف المؤلف Unknown Zombie, مصدر
ما هي أفكارك حول مخطط الجدول بحيث يكون العمود الفريد الوحيد هو المفتاح الأساسي المتزايد تلقائيًا في إنشاء قاعدة البيانات؟ لا سيما بالنسبة للجداول التي ليس لها مفتاح خارجي ولكن المفتاح الأساسي هو المفتاح الخارجي للعديد من الجداول المرتبطة؟
وأضاف المؤلف Unknown Zombie, مصدر
Person p1 = new Person();
p1.ID=GUID.NewGUID();
PersonRepository.Insert(p1);

هذا هو السبب الأكثر أهمية من أجل استخدام GUIDs.

حقيقة أن بإمكانك إنشاء معرف فريد دون أن تعرف شفرتك معرفة أو التواصل مع طبقة ثباتك هي فائدة كبيرة.

يمكنك التأكد من أن كائن الشخص الذي أنشأته للتو على خادمك أو هاتف جهاز الكمبيوتر أو الكمبيوتر المحمول أو جهاز غير متصل بالإنترنت أو أي شيء فريد في جميع خوادمك في جميع أنحاء العالم تم توزيعه.

يمكنك التمسك بها في أي نوع من قاعدة البيانات rdb أو no-sql أو الملف أو إرسالها إلى أي خدمة ويب أو التخلص منها على الفور على أنها غير مطلوبة

لا لن تصطدم أبداً.

نعم ، يمكن أن تكون الإدخالات أبطأ قليلاً لأن المؤشر قد يحتاج إلى أن يكون مغشوشًا.

نعم إنها أكبر من كثافة العمليات.

  • وتحرير. اضطر إلى إطلاق النار قبل الانتهاء.

أنا أعرف الكثير من الناس يشعرون بقوة حول ints لصناعة السيارات وهذا موضوع مثير للجدل مع DBAs

لكنني حقا لا أستطيع أن أقول بقوة بما فيه الكفاية كيف هي أدلة متفوقة. يجب عليك استخدام الأدلة من خلال افتراضي في أي تطبيق.

auto incts بها العديد من العيوب

  • يمكنك استخدام No-Sql الموزع db. أنت ببساطة لا تستطيع التحدث مع كل الحالات الأخرى لمعرفة الرقم التالي.

  • أنت تستخدم نظام قائمة انتظار الرسائل. تحتاج الأشياء إلى معرفات قبل أن تصل إلى db

  • أنت بصدد إنشاء العديد من العناصر وتعديلها قبل الحفظ. يحتاج كل منهم إلى معرف قبل أن تضغط على db

  • تريد حذف وإعادة إدراج الصفوف. تأكد من أنك لا تحتسب معرفاتك التي تعمل تلقائيًا وانتهى!

  • لا تريد عرض عدد الطلبات التي قمت بجمعها هذا العام لكل مستخدم

  • تريد نقل بيانات مجهولة المصدر من الإنتاج للاختبار والحفاظ على العلاقات سليمة. ولكن لا تحذف جميع بيانات الاختبار الحالية.

  • تريد دمج منتج المستأجر الفردي في قاعدة بيانات متعددة للمستأجرين ، لكن كل شخص لديه طلب 56.

  • يمكنك إنشاء كائنات ثابتة ولكن سريعة الزوال. (الطلبات غير المكتملة) مرة أخرى ، لا تستخدم جميع أحبارك التي تحتوي على أشياء لم تعد موجودة.

القائمة لا حصر لها وكلها مشاكل حقيقية تحدث للناس طوال الوقت. على عكس نفاد مساحة الأقراص بسبب وجود أعمدة FK أكبر قليلاً

وأخيرًا ، تكون المشكلة الهائلة مع ints هي نفادها !!! موافق من الناحية النظرية لا أميل ، هناك كميات. لكن في الواقع أنت تفعل لأن الناس لا يعاملونهم كأرقام عشوائية بلا معنى. يفعلون أشياء مثل

  • أوه ، لا أريد أن يعتقد العملاء أننا جديدون. تبدأ من 10000

  • كان عليّ استيراد حمولة من البيانات ، لذا قمت بتعبئة البذور إلى 1 متر فقط حتى نعرف ما يتم استيراده

  • نحتاج إلى فئة البيانات. تبدأ كل فترة في المليون التالية حتى نتمكن من استخدام الأرقام الأولى كرقم سحري

  • حذفت وأعدت استيراد جميع البيانات مرة أخرى باستخدام معرفات جديدة. نعم حتى سجلات التدقيق.

  • استخدم هذا الرقم ، وهو مفتاح مركب ، كمعرّف لهذا الشيء الآخر

2
وأضاف
يعتمد على ما تقصده بـ "collide". في نفس الجدول ، فإن فرصة اصطدام السيارات inc هي صفر.
وأضاف المؤلف sgwill, مصدر
أعتقد أنه سيكون هناك بعض التطبيقات الغريبة التي تكون فيها الأدلة أفضل. فريدة من نوعها ليست أهم شيء للنظر فيها. مبالغ فيها بشكل كبير من "ثغرات" النمل ، ولا تعتبر أيًا من عيوب الأدلة الكثيرة.
وأضاف المؤلف Andy, مصدر
-1 لـ "يجب عليك استخدام الأدلة بشكل افتراضي في أي تطبيق." هذا يعتمد. وكما أظهر الآخرون ، لا يمكن ضمانًا أن تكون GUIDs/UUIDs فريدة من نوعها.
وأضاف المؤلف Geocode.Farm Staff, مصدر
"يعتمد الأمر" على أن الإجابات غير مجدية ، ومن المؤكد أن هناك بعض التطبيقات الغريبة التي يكون فيها int أفضل. لكن هناك احتمالات بأن تطبيقك ليس واحدًا منهم. تعد المعرفات الفريدة العمومية (GUIDs) أكثر الأشياء التي يمكنك الحصول عليها
وأضاف المؤلف Ewan, مصدر
أكثر احتمالا أن تصطدم السيارات المدمجة من دليل
وأضاف المؤلف Ewan, مصدر
هذا غير صحيح. يمكنك بسهولة الحصول على تصادم Int ببساطة عن طريق إدخال قيمة أعلى من البذور الحالية أو إعادة تعيين البذور إلى قيمة أقل
وأضاف المؤلف Ewan, مصدر
لا يوجد شيء خاطئ فيما يتعلق بهذه الإجابة ، لكنني أود أن أتخلص من المزيد من التخفيضات) ربما نوضح التحذير بأنه على الرغم من أن تطبيقات الحياة الحقيقية لن تواجه تصادمات ، فمن الممكن نظريًا. (أو ربما 45 + قاعدة بيانات exabyte هي أكثر انتشارا مما كنت اعتقد ...). على الرغم من أنني أعتقد أن اللغة "السبب الأكثر أهمية" قوية بعض الشيء ، وهذا هو ما أجده أكثر فائدة.
وأضاف المؤلف Pascalerino, مصدر

مثل أي شيء ، هناك مزايا وعيوب للقيام بذلك:

الجيد:

  1. مفاتيحك دائمًا بنفس الطول (يمكن أن تحتوي قواعد البيانات الكبيرة جدًا على مفاتيح كبيرة جدًا)

  2. الفريد مضمون إلى حد كبير - حتى عندما تنشئه من نظام منفصل ، و/أو لم تقرأ آخر معرّف من قاعدة البيانات

السوء:

  1. كما ذكرنا كثيرًا أعلاه - أكبر الفهارس ومخزن البيانات.

  2. لا يمكنك الطلب باستخدام المعرّف ، يجب عليك الطلب باستخدام شيء آخر. المزيد من الفهارس ، وربما أقل كفاءة.

  3. إنهم أقل قابلية للقراءة. عادةً ما تكون الأعداد الصحيحة أسهل في التحليل والتذكر والكتابة للناس. يمكن أن يؤدي استخدام المعرفات الفريدة العمومية (GUIDs) مثل المعرفات الموجودة في جمل WHERE عبر جداول متعددة مرتبطة إلى ذوبان رأسك.

مثل كل شيء ، استخدمها حيثما كان ذلك مناسبًا ، لا تكون عقائديًا - في كثير من الحالات تكون الأعداد الصحيحة المتزايدة تلقائيًا أفضل ، وتكون GUIDs أحيانًا رائعة.

1
وأضاف

نعم ، يمكنك استخدام المعرف الفريد العمومي (GUID) كمفتاح أساسي. الجانب السلبي هو الحجم والتجزئة السريعة للمؤشر.

ما لم تكن بحاجة إلى التفرد عبر قواعد البيانات (مثل الكتلة) ، يُفضل عدد صحيح.

0
وأضاف
قد تنتج المعرفات GUID نفس المعرّف الفريد العمومي (GUID) أكثر من مرة ، يوجد هنا خلل. ما إذا كانت ستعتمد أم لا على مستوى التفاصيل الخاصة بها ، وذلك بشكل أساسي على الفترة الزمنية بين علامات التأشير. مثلا مولد على مدار الساعة قد علامة فقط على كل 100ms ، مما يؤدي إلى 2 المعرفات الفريدة GUIDs المطلوبة ضمن أن 100ms على هذا الجهاز يجري متطابقة. هناك طرق لتجنب ذلك ، في الغالب ، ولكن العديد من المولدات GUID تعمل بشكل كامل خارج عنوان IP و/أو عنوان MAC والطابع الزمني.
وأضاف المؤلف jwenting, مصدر

هنا هي وجهة نظري حول هذه المسألة - الحل هو منزل في منتصف الطريق بين GUID والقيم int ، مع الأخذ الأفضل من كليهما.

يولد الصف قيمة معرّفة عشوائية زائفة (ولكنها تزداد بمرور الوقت) ، وهي مشابهة لـ Comb GUID .

وتتمثل الميزة الأساسية في أنها تسمح بتوليد قيم المعرف على العميل ، بدلاً من استخدام قيم الزيادة التلقائية التي تم إنشاؤها على الخادم (والتي تتطلب رحلة ذهاب وإياب) مع عدم وجود خطر تقريبًا للقيم المكررة.

تستخدم القيم التي تم إنشاؤها فقط 8 بايت بدلاً من 16 لـ GUID ، ولا تعتمد على ترتيب فرز قاعدة بيانات محدد (مثل Sql Server for GUIDs ). يمكن توسيع القيم لاستخدام النطاق الطويل غير الموقّع بالكامل ، ولكن قد يتسبب ذلك في مشاكل مع أي قاعدة بيانات أو مستودع بيانات آخر يحتوي فقط على عدد صحيح من الأرقام.

public static class LongIdGenerator
{
   //set the start date to an appropriate value for your implementation 
   //DO NOT change this once any application that uses this functionality is live, otherwise existing Id values will lose their implied date
    private static readonly DateTime PeriodStartDate = new DateTime(2017, 1, 1, 0, 0, 0, DateTimeKind.Utc);
    private static readonly DateTime PeriodEndDate = PeriodStartDate.AddYears(100);
    private static readonly long PeriodStartTicks = PeriodStartDate.Ticks;
    private static readonly long PeriodEndTicks = PeriodEndDate.Ticks;
    private static readonly long TotalPeriodTicks = PeriodEndTicks - PeriodStartTicks;

   //ensures that generated Ids are always positve
    private const long SEQUENCE_PART_PERMUTATIONS = 0x7FFFFFFFFFFF; 

    private static readonly Random Random = new Random();

    private static readonly object Lock = new object();
    private static long _lastSequencePart;

    public static long GetNewId()
    {
        var sequencePart = GetSequenceValueForDateTime(DateTime.UtcNow);

       //extra check, just in case we manage to call GetNewId() twice before enough ticks have passed to increment the sequence 
        lock (Lock)
        {
            if (sequencePart <= _lastSequencePart)
                sequencePart = _lastSequencePart + 1;

            _lastSequencePart = sequencePart;
        }

       //shift so that the sequence part fills the most significant 6 bytes of the result value
        sequencePart = (sequencePart << 16);

       //randomize the lowest 2 bytes of the result, just in case two different client PCs call GetNewId() at exactly the same time
        var randomPart = Random.Next() & 0xFFFF;

        return sequencePart + randomPart;
    }

   //used if you want to generate an Id value for a historic time point (within the start and end dates)
   //there are no checks, compared to calls to GetNewId(), but the chances of colliding values are still almost zero
    public static long GetIdForDateTime(DateTime dt)
    {
        if (dt < PeriodStartDate || dt > PeriodStartDate)
            throw new ArgumentException($"value must be in the range {PeriodStartDate:dd MMM yyyy} - {PeriodEndDate:dd MMM yyyy}");

        var sequencePart = GetSequenceValueForDateTime(dt.ToUniversalTime());
        var randomPart = Random.Next() & 0xFFFF;
        return ( sequencePart << 16 ) + randomPart;
    }

   //Get a 6 byte sequence value from the specified date time - startDate => 0 --> endDate => 0x7FFFFFFFFFFF
   //For a 100 year time period, 1 unit of the sequence corresponds to about 0.022 ms
    private static long GetSequenceValueForDateTime(DateTime dt)
    {
        var ticksFromStart = dt.ToUniversalTime().Ticks - PeriodStartTicks;
        var proportionOfPeriod = (decimal)ticksFromStart/TotalPeriodTicks;
        var result = proportionOfPeriod * SEQUENCE_PART_PERMUTATIONS;
        return (long)result;
    }

    public static DateTime GetDateTimeForId(long value)
    {
       //strip off the random part - the two lowest bytes
        var timePart = value >> 16;
        var proportionOfTotalPeriod = (decimal) timePart/SEQUENCE_PART_PERMUTATIONS;
        var ticks = (long)(proportionOfTotalPeriod * TotalPeriodTicks);
        var result = PeriodStartDate.AddTicks(ticks);
        return result;
    }
}
0
وأضاف