فصل جدول المستخدم عن جدول الأشخاص في قاعدة البيانات العلائقية

Question

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

هل من المعقول إنشاء جدول ثاني، people_tb, ، هذا هو الجدول العلائقي الرئيسي ومخزن البيانات، واستخدم فقط users_tb للمصادقة؟هل يفصل user_tb من people_tb تقديم أي مشاكل؟إذا كان هذا يتم بشكل شائع، فما هي بعض الاستراتيجيات والحلول بالإضافة إلى العيوب؟

Answer 1

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

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

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

في طلبي، أكتبه بلغة Ruby on Rails، لذلك أفعل باستمرار أشياء مثل member.user.name، حيث إذا احتفظت بهما معًا، فسيكون مجرد اسم الموظف أو اسم المستخدم.

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

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

Answer 2

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

Answer 3

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

Answer 4

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

ثم بالنسبة للأشخاص الذين يقومون بتسجيل الدخول، يمكنك الحصول على users الجدول الذي له علاقة 1 ~ 1 مع people.يمكن لهذا الجدول تخزين اسم المستخدم وكلمة المرور.

Answer 5

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

Answer 6

معقول جدا.

على سبيل المثال، قم بإلقاء نظرة على جداول الخدمات aspnet_* هنا.

يحتوي مخططهم المدمج على aspnet_Users و aspnet_Membership مع وجود جدول لاحق يحتوي على مزيد من المعلومات الموسعة حول مستخدم معين (كلمات المرور المجزأة، وما إلى ذلك) ولكن aspnet_User.UserID يتم استخدامه في الأجزاء الأخرى من المخطط للتكامل المرجعي وما إلى ذلك.

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

Answer 7

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