هل من الأفضل إنشاء جدول SQL للحصول على تطابق أم عدم إرجاع أي نتيجة

Question

لدي سؤال تصميم مثير للاهتمام.أقوم بتصميم الجانب الأمني ​​لمشروعنا، للسماح لنا بالحصول على إصدارات مختلفة من البرنامج بتكاليف مختلفة وأيضًا للسماح للمستخدمين من نوع المدير بمنح أو رفض الوصول إلى أجزاء من البرنامج لمستخدمين آخرين.سيتم نقله إلى الويب واستضافته على خوادمنا.

أنا أستخدم خيار السماح أو الرفض البسيط لكل "مورد" أو شاشة.

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

لقد وضعت طريقتين لهذا الأمر في الاعتبار، وكنت أشعر بالفضول بشأن أيهما أفضل لخادم SQL من حيث الأداء.

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

أعتقد أن هذا سيعني جدولًا أصغر، ولكن هل ستبحث الاستعلامات في الجدول بأكمله لتحديد عدم وجود تطابق؟

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

أفكار؟

Answer 1

إذا كان الأمر سيكون السماح/الرفض فقط، فإن جدول الربط البسيط بين المستخدمين والموارد سيعمل بشكل جيد.إذا كان هناك إدخال مرتبط بمورد المستخدم في جدول الارتباط، فاسمح بالوصول.

UserResources
-------------
UserId FK->Users
ResourceId FK->Resources

وسيكون SQL شيء من هذا القبيل

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid)
set @allow=1;

باستخدام الفهرس المجمع على (UserId وResourceId)، سيكون الاستعلام سريعًا للغاية حتى مع وجود ملايين السجلات.

Answer 2

سأصوت للخيار ب.إذا اتبعت الخيار أ وافترضت أنه في حالة وجود مستخدم، فيمكنه الدخول، فسوف تواجه في النهاية مشكلة أنك تريد رفض وصول المستخدم، دون إزالة سجل المستخدم.

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

Answer 3

ب.فهو يسمح بإجراء فحوصات أفضل بكثير لمعرفة ما إذا كانت البيانات كاملة (على سبيل المثال، عند إضافة ميزة مسموح بها/يمكن رفضها).

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

Answer 4

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

User1 is in group1 and group2.  
User2 is in group1  
User3 is in group2 

---

Folder1 allows group1 and deny group2.  
User1 is denied.  
User2 is allowed.  
User3 is denied. 

أعتقد أن نهجك users1 سيكون مسموحًا به.