في تطبيق Web Driven قاعدة البيانات، ماذا يجب أن يرى المستخدم عند عدم توفر قاعدة البيانات؟

Question

إذا اعتمد تطبيق ويب على قاعدة بيانات لخدمة المحتوى الديناميكي وأن المحتوى غير متوفر لأي سبب من الأسباب (خادم قاعدة البيانات لأسفل، وما إلى ذلك)، فما هي الطريقة المفضلة للتعامل مع هذا السيناريو؟

1. إعادة توجيه الزائر إلى صفحة مخصصة 404؟
2. عرض الصفحة على أي حال ولكن تشمل نوع من رسالة الخطأ حيث سيكون المحتوى خلاف ذلك؟
3. عرض صفحة ذات صلة بها محتوى ثابت؟
4. آخر؟

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

Answer 1

# 3 إذا استطعت (مثل لقطة من المحتوى الديناميكي الذي اتخذ كل 20 دقيقة)، ولكن جعله من الواضح أن هذا محتوى ثابتا اعتبارا منu003Ctime> وسيتم تحديثها بمجرد حل مشاكل النظام.

# 2 إذا كنت لا تستطيع، طالما أن الخطأ مقروء بشري وليست طباعة حرفية لتتبع مكدس استثناء من جافا أو سوميسوش.

Answer 2

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

إذا كنت ستعود بعض حالة HTTP أخرى إلى 200، فسوف أوصي بالرد 503 "خدمة غير متوفرة". هذا أكثر تشددا عن خطأ مؤقت مع التطبيق، بدلا من أن يكون هناك خطأ في طلب HTTP.

Answer 3

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

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

لذا؛ يعتمد ذلك على ما تقدمه الصفحة، وما إذا كان يمكن أن يوفر أي شيء مفيد أم لا دون الخلفية.

Answer 4

أعتقد أن # 3 ربما الأفضل، ولكن ليس دائما ممكنا. إذا لم يكن ذلك ممكنا، فإن نوعا من "الصعوبات التقنية، يرجى الوقوف من قبل ..." قد يكون أفضل (من الواضح، يمكنك تغيير الصياغة إلى شيء أفضل). فقط تجنب خطأ في الطباعة فعليا: err_123 / sigsegv! (أو شيء من هذا القبيل) في الحروف الحمراء الكبيرة. يجعل المستخدمين يعتقدون أن تطبيقك مكسور وقد لا يعودون.