تقييم الموضوع :
  • 0 أصوات - بمعدل 0
  • 1
  • 2
  • 3
  • 4
  • 5
سؤال عن حقل primry key في sql server
#1
السلام عليكم ورحمة الله وبركاته 

أسعد الله مساءكم 


عندي عدة جداول جميعها فيها حقل primry key طبعاً متزايد 1 

المشكلة في التسجيل يكون متسلسل وممتاز بعد فترة يتغير التسلسل بزيادة 1000 مثلاً عن آخر رقم 

مع العلم اني ملغي شي اسمه حذف نهائي من القاعدة 

صارت معي كم مره فأقوم البيانات scrept ثم اعلم لها 

1- DELETE FROM table_name

2- (DBCC CHECKIDENT(tblUsersDepartmentsM, RESEED, 0


ثم اعيد البيانات وتستمر على وضع طبيعي وتسلسل جيد ثم بعد مده ترجع نفس الحاله 


سألت بعض المختصين فقالو هذه طبيعية في sql server 


بحثت في بعض المواقع لقيت انه في مشكلة فعلاً من سؤال الناس 

http://www.dfarber.com/computer-consulti...-sql-2012/
-------------------------------------------------------------------

ما رأيكم بهذه المشكلة هل هي فعلاً مشكلة معروفه ويستلزم انا نغير المتزايد ونخليه بالكود بالبحث عن آخر رقم +1

او مشكلة عندي فقط



بكم نرتقي ونسأل الله لنا ولكم التوفيق ،،
الرد }}}
تم الشكر بواسطة:
#2
تقصد بيبقى 1001
1002 وهكذا ؟

عموما فى الرابط الى انت ارفقته الحل انا مجربه بنفسى وبتحصل معى كل فترة
وهتظبط معاك ان اشء الله
الرد }}}
تم الشكر بواسطة: عبدالله الدوسري , hglogtd , hglogtd , elgokr
#3
الي اقصده انه ماشي على الترتيب من فترة وصل الترتيب مثلاً 100 الي بعده المفروض 101

والمشكلة ما يظهر 101 يظهر 250 مثلا او 1200 مثلاً يعني قفزه ليست برقم او رقمين بل بعض الاحيان الى 1000 زيادة عن آخر رقم 


شاهد احد الجداول


الملفات المرفقة صورة/صور
   



بكم نرتقي ونسأل الله لنا ولكم التوفيق ،،
الرد }}}
تم الشكر بواسطة: elgokr
#4
الحل بسيط: قم بتمرير الغطاء وعد للنوم وريح بالك. لا يجب أن تهتم بهذا الأمر.

الـ 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



حبيت أطرح معلومات أتمنى تكون مفيدة للبعض
عن تجربة شخصية
الرد }}}
#5
الله يعطيك العافيه ، معلومات قيمه وبارك الله فيك وكنت متوقع انها ما تحصل ابداً وأن المشكلة هي خلل في البرمجة او في العلاقات 

لكن وضحت الفكره ووصلت المعلومه بارك الله فيك اخي عبدالله



بكم نرتقي ونسأل الله لنا ولكم التوفيق ،،
الرد }}}
#6
انا استعين بالباراميتر t272 لحل المشكلة
جماعة ميكروسوفت يقولو ان من الافضل استخدام حقل sequence

الرد }}}
تم الشكر بواسطة: عبدالله الدوسري , hglogtd , elgokr
#7
(19-09-18, 11:52 PM)hglogtd كتب : الي اقصده انه ماشي على الترتيب من فترة وصل الترتيب مثلاً 100 الي بعده المفروض 101

والمشكلة ما يظهر 101 يظهر 250 مثلا او 1200 مثلاً يعني قفزه ليست برقم او رقمين بل بعض الاحيان الى 1000 زيادة عن آخر رقم 


شاهد احد الجداول

كده فهمتك
تقدر تاخد سكربت من الداتا بيز وتمسح الداتا بيز من السيرفر وتشغل الاسكربت بيعيد الترقيم من الاول
الرد }}}
تم الشكر بواسطة: elgokr



التنقل السريع :


يقوم بقرائة الموضوع: بالاضافة الى ( 1 ) ضيف كريم