الحل بسيط: قم بتمرير الغطاء وعد للنوم وريح بالك. لا يجب أن تهتم بهذا الأمر.
الـ IDENTITY غالباً ما تكون للـ
primary key هو رقم
لا معنى له ، الـ IDENTITY
مصمم لخلق فجوات في الترتيب
( جميع إصدارات SQL Server بدون إستثناء ).
أما القفز بمقدار 1,000 للـ INT ,وبمقدار 10,000 للـ BIGINT , أتى بعد إصدارة 2008 , لتحسين الأداء , فهو يقوم بحفظ هذة الأرقام الألف في الكاش لسرعة الإجراء.
أما الفجوات فهي موجودة منذ الأزل :
بمعنى ، إذا قمت بإدراج صف ثم العودة إلى الخلف ، يتم فقدان هذا الرقم. وهذه الطريقة لتحسين التزامن.
مثال آخر : إذا كنت تقوم بإجراء ( إدراج أو إضافة سجل جديد ) وحدث خطأ في هذا الإجراء داخل الـ SQL Server ( ولم تتم عملية الإدراج لأي سبب كان ) , ( رقم الـ IDENTITY لهذة العملية يعتبر مفقود ولن يتكرر)
ولو كنت تقوم بعمليات إدراج متعددة مع أخطاء ستفقد الكثير من الأرقام . ولن يفيدك الأمر
(DBCC CHECKIDENT(tblUsersDepartmentsM, RESEED, 0 نهائياً
( هذا مثال على سيناريو واحد وهناك سيناريوهات كثيرة لحدوث مثل هذا الأمر )
لديك في الجدول سجلات بأرقام IDENTITY متسلسلة في البداية والحمد لله ,,, لاحظ معي السيناري التالي :
سجل الـ IDENTITY رقم : 1 <--- السجل الأول
سجل الـ IDENTITY رقم : 2
سجل الـ IDENTITY رقم : 3
سجل الـ IDENTITY رقم : 4
سجل الـ IDENTITY رقم : 5
----------------------------------------------
محاولت إدارج فاشلة ( سجل الـ IDENTITY رقم : 6 ) مفقود <---- مفقود يعني لن يتم إستخدامة ( سياية SQL Server ) أي رقم يتم إنشائة , نحج أم فشل , لن يتكرر أبداً .
محاولت إدارج فاشلة ( سجل الـ IDENTITY رقم : 7 ) مفقود
محاولت إدارج فاشلة ( سجل الـ IDENTITY رقم : 8 ) مفقود
----------------------------------------------
سجل الـ IDENTITY رقم : 9
سجل الـ IDENTITY رقم : 10
سجل الـ IDENTITY رقم : 11
----------------------------------------------
محاولت إدارج فاشلة ( سجل الـ IDENTITY رقم : 12 ) مفقود
----------------------------------------------
سجل الـ IDENTITY رقم : 13
سجل الـ IDENTITY رقم : 14
سجل الـ IDENTITY رقم : 15
سجل الـ IDENTITY رقم : 16
سجل الـ IDENTITY رقم : 17
سجل الـ IDENTITY رقم : 18
سجل الـ IDENTITY رقم : 20
سجل الـ IDENTITY رقم : 21
----------------------------------------------
محاولت إدارج فاشلة ( سجل الـ IDENTITY رقم : 22 ) مفقود
----------------------------------------------
السجلات باللون الأخظر هي الموجودة في الجدول فقط
لن تستفيد من الأمر
(DBCC CHECKIDENT(tblUsersDepartmentsM, RESEED, 0
ولن يفيدك أيضاً
Trace Flag 272
هناك أرقام في المنتصف مفقودة
الآن ماذا ستفعل لو كنت تقدم خدماتك لشركة أو قمت ببيع نظام مبيعات مثلاً , ولديها سجلات كثيرة وحدثت أخطاء كثيرة ( إعادة التصميم ستكون مكلفة )
إذا كانت متطلبات العمل لديك تستوجب أن تكون الأرقام متسلسلة ،
فيجب أن تعلم أنه يجب ألا تستخدم الـ IDENTITY في المقام الأول. وأن تصميم قاعدة البيانات خطاً فادح إذا استخدمت الـ IDENTITY ليكون مثلاً رقم فاتورة أو ما شابة.
وبطبيعة الحال ، يجب ألا تستخدم TF272 - لأنها لا تفيد أبداً في تحسين الأداء.
يجب على الأقل تكون هناك معرفة ببعض المعلومات ( تصرفات الـ Sql Server ) وكيف يقوم الـ SQL Server بعمل الأمور وكيف يديرها وما هو السيناريو الذي يجري في خلفية الـ SQL Server
وظيفة الـ IDENTITY : تم تصميمة ليخدم شيء وحيد في منظومة الـ SQL Server وهو ( الـ
primary key ) , ( فهي لظمان عدم تكرار الرقم في المفاتيح الأساسية -
primary key - لعمل الحذف والتحديث على السجلات ومفتاح يستخدم في الخارج لربط العلاقات مع جداول أخرى ) ولا يهم إذا كان متسلسل أم لا. ومن الخطاً في التصميم إستخدامة في أشياء أخرى ( تتطلب رقم متسلسل )
تستطيع إستخدام الـ IDENTITY في أمور تخصك أو في أمور أخرى لأغراض معينة تخدمك , لا مانع , ولكن تذكر أنا موجودة وسبب وجودها هي المفاتيح الأساسية.
وظمان تسلسلها مستحيل
إذا كنت ترغب في إستخدام رقم متسلسل ( فيجب عيك أن لا تستخدم الـ IDENTITY )
والقيام بنظام يخدم متطلبات هذا الرقم المتسلسل
أي بما معناه أن تصمم كود في قاعدة البيانات أو في البرنامج أياً كان نوع الفكرة التي ستطبقها أو مكان تطبيقها , المهم أن يعتني بموظوع الأرقام المتسلسلة التي تخدم برنامجك بشكل معين.
وبما أن الموضوع عن SQL Server فالأفضل طبعاً أن يكون الكود أو الفكرة التي ستعتني بها الرقم المتسلسل داخل قاعدة البيانات , بعيداً عن البرنامج.
موضوع أن يقفز الرقم بمقدار 1,000 , أو 10,000
(وهو أمر لا يحدث إلى قليل جداً أو ممكن أن يكون من النادر لأنة لا يحدث عند إعادة تشغيل السيرفر بشكل نظامي وطبيعي , بل يحدث عندما يحصل إنهيار للـ SQL Server أو عند قطع الكهرباء بشكل مفاجئ أو لأسباب منعت الـ SQL Server من الإغلاق أو إعادة التشغيل بشكل نظامي )
تحاول Microsoft تحسين الأداء , بطريقة الكاش , ولأنها تعمل أن أصول التصميم أن لا يعتمد أحد على تسلسل الـ IDENTITY .
ولأسباب أخرى تخص السيرفرات المتصلة ببعضها وتقوم بأعمال مزامنة في بعض التعقيد , يتيح الفرصة للسيرفر أن يقوم بعد الإنهار ويعطي قفزة في الأرقام لدواعي الإحتياط من تظارب أرقام سجلات تأتي من بعيد وليس من نفس السيرفر.
لذلك وضعت Microsoft خيار جديد (
IDENTITY_CACHE ) في النسخة الجديدة يمكنك من تعطيل نظام الكاش لأرقام الـ IDENTITY : وهو بشكل إفتراضي مفعل (
ON )
أي بطئ في نظام إدراج السجلات ( خلق أرقام جديدة للسجلات الجديدة ) سيكون بسبب تعطيل الكاش
كود :
-- Set IDENTITY_CACHE = OFF
ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF
GO
حبيت أطرح معلومات أتمنى تكون مفيدة للبعض
عن تجربة شخصية