المستخدمين الذين يطلبون قاعدة البيانات الشيوعية
https://stackoverflow.com/questions/1730298
-
20-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا في المراحل المبكرة من تطوير نظام مدفوع قاعدة البيانات والأكبر جزء من النظام يدور حول نوع الميراث من العلاقة. هناك كيان أحد الوالدين مع حوالي 10 أعمدة وهناك حوالي 10 كيانات أطفال يرثون من الوالد. سيكون لكل كيان طفل حوالي 10 أعمدة. اعتقدت أنه من المنطقي إعطاء كيان الوالد طاولته الخاصة وإعطاء كل من الأطفال طاولاتهم الخاصة - وهي هيكل طاولة لكل فرعية.
اليوم، طلب مستخدمي رؤية هيكل النظام الذي قمت بإنشائه. انخفضوا في فكرة هيكل الطاولة لكل فرعية. سوف يفضلون طاولة عمود كبيرة ~ 100 لأنه سيكون أسهل بالنسبة لهم لأداء استفساراتهم المخصصة الخاصة بهم.
يجب أن أفكر في تنظيم قاعدة البيانات من أجل المستخدمين؟
المحلول
بالطبع لا. يمكنك دائما إنشاء طريقة عرض في وقت لاحق لإظهارها ما يريدون رؤيته.
نصائح أخرى
إنهم يطلبون بفعالية تقرير.
يمكنك امنحهم الوصول إلى عرض تحتوي على جميع الحقول التي تتطلبها ... بهذه الطريقة لا تفشل نموذج البيانات الخاص بك.
لا. هيكل البيانات بشكل صحيح وإذا كان المستخدمون بحاجة إلى عرض شيوفي للبيانات إنشاءه كمنظر في قاعدة البيانات.
بدلا من ذلك، فكر في أن RDBMS ليس أداة التخزين المناسبة لهذا المشروع.
هم المستخدمون وليس مبرمجات النظام لسبب ما. توفير واجهة منفصلة لاستفساراتها. يمكن للمستخدمين السلطة مثل هذا أن يكون كلاهما مفيدا وألم للتعامل معه. فقط اشرح أنك بحاجة إلى قاعدة البيانات صممت طريقة معينة حتى تتمكن من القيام بعملك، الفترة. بمجرد أن ينجزك وتقديم وسيلة أخرى لجعل الاستعلام أسهل.
ماذا يعرفون!؟ هل يمكن أن تجادل ذلك المستخدمين يجب أن لا تواجه الوصول المباشر إلى قاعدة بيانات في المقام الأول.
القيام بذلك يترك لك فتح مشكلات أداء هائلة، لمجرد أن زوجين من المستخدمين يقومون بتشغيل استفسارات سخيفة.
ماذا عن إذا قمت بإنشاء طريقة عرض في تنسيق المستخدمين الذين يريدون ذلك أثناء الحفاظ على طاولة طبيعية بشكل صحيح؟
بصرف النظر عن الكثير من الأسباب الفنية لاقتراح المستخدمين أو مقابل اقتراح المستخدمين، يجب أن تكون في نفس الصفحة في توصيل عواقب مختلفة من السخرية و (الأهم من ذلك) التكاليف من تلك العواقب. إذا كان المستخدمون عملائك ويدفعون لك وظيفة، فشرح ذلك سيى الأفكار "المقترحة" قد تكلفها المزيد من المال في وقت التطوير، موارد الأجهزة الإضافية، إلخ.
نأمل أن توضح ذلك بطريقة تعرض خبرتك ولماذا تكون فكرتك قيمة أفضل بكثير لمستخدميك على المدى الطويل.
كما ذكر الجميع أكثر أو أقل، فإن هذه الطريقة تكمن الجنون، ويمكنك دائما بناء رؤية.
إذا لم تتمكن فقط من الوصول إليها في هذه النقطة، ففكر في إظهار هذا الخيط وعدد الإيجابيات الذين أثروا في القول أن المستخدمين يتدخلون مع الأشياء التي لا يفهمونها تماما، وسوف يكون التأثير مؤسسة تقويض.
جزء كبير من الحرفية المطور هو الشعور بما لن ينجح على المدى الطويل، وقواعد التطبيع شبه كونيا تقريبا في هذا الصدد. هناك مواقف تحتاج فيها إلى تنظيم (مستودعات البيانات، إلخ) ولكن هذا لا يبدو وكأنه أحدهم!
كما أنه يبدو كما لو كنت قد يكون لديك علامة تجارية مقلقة بشكل خاص للمستخدم على يدك - مطور Amatuer الذي يعتقد أنهم قادرون على تحسين عملك أنفسهم فقط إذا كان لديهم الوقت فقط. قد يساعد هذا أو لا يساعد ذلك، لكنني وجدت أن هذه الأنواع تستجيب بشكل جيد للعرض - عدة مرات الآن وجدت أنه إذا كنت أرتدي حادة وإظهار القليل من القوة في شخصيتي، فإنها تساعدهم على الشعور أنا خبير ويمنع حفنة من المشاكل قبل أن تبدأ.
أود أن أوصي بشدة الخروج بإجابة لا ينطوي على شخص يشغل تقارير مباشرة مقابل قاعدة البيانات الخاصة بك. اللحظة التي تحدث، يتم تعيين هيكل DB الخاص بك في الحجر ويمكنك النظر فيها بشكل أساسي في الإرث.
وجهة نظر هي بداية جيدة، ولكن في وقت لاحق عليك أن ترغب في بناء هذا كتصدير، لتفكيك المزيد. بالطبع، ستصادف شخصا يريد بيانات "الوقت الحقيقي". عادة ما تكشف تحليل الأعمال السليم أن هذا غير ضروري. لا يتم التعامل مع متطلبات الوقت الفعلي في الوقت الفعلي من خلال أنظمة الإبلاغ.
فقط أن تكون واضحا: كنت شخصيا أن أؤيد الجدول لكل منهج الفرعية، لكنني لا أعتقد أنه في الواقع مشكلة كبيرة حيث ستكون الجداول المباشرة لإيقاف المعاملات.
وأود أن تختار عرض (كما اقترح الآخرون) أو وظيفة مضمنة الجدول (فوائد ذلك، هل تحتاج إلى معلمات - مثل نطاق تاريخ أو حساب عملاء - والتي يمكن أن تساعد في إيقاف المستخدمين من الاستعلام دون أي حدود مساحة المشكلة) أولا. يعد Velline TVF هو في الحقيقة عرضا غير رسمي وهو أقرب بكثير من وجهة نظر من حيث كيف يعاملها المحرك أكثر مما هو عليه وظيفة مائدة متعددة البيان أو وظيفة العددية، والتي يمكن أن تؤدي بشكل سيئ بشكل لا يصدق.
ومع ذلك، في بعض الحالات، يمكن أن يؤثر ذلك على أداء الإنتاج إذا كان العرض معقدا أو مكثفا. من خلال استفسارات مستخدمي مخصصة بشكل سيء، يمكن أن تسبب أيضا أقفال تستمر لفترة أطول أو تصعيد أبعد مما ستحصل على استعلام أفضل مبني. من الممكن أيضا استخدام المستخدمين نموذج بيانات ER وإنتاج أرقام مضروبة في الحالات التي توجد فيها العديد من العلاقات أو العديد من العلاقات. قد يكون الخيار التالي لتحقيق هذه الآراء مع فهارس أو جعل الجداول والحفاظ عليها محدثة، مما يجعلنا أقرب إلى خياري التالي ...
لذلك، نظرا لهؤلاء العيوب الخيار الرأي والتفكير بالفعل في التخفيف من خلال البدء في إجراء نسخ من البيانات، فإن الخيار التالي الذي أعتبره إصدار نسخة منفصلة للقراءة فقط (هؤلاء المستخدمين) من البيانات التي يتم تنظيمها بشكل مختلف وبعد عادة، أود أولا أن ننظر إلى مخطط نجمة على غرار كيمبالبر. لا تحتاج إلى الحصول على مستودع بيانات متسق من الوقت الكامل. بالطبع، هذا خيار، ولكن يمكنك ببساطة الحفاظ على نموذج الإبلاغ حتى الآن مع البيانات. إن مخططات النجوم هي شكل خاص من التشكيز، وهي جيدة بشكل خاص للإبلاغ العددي، ولا ينبغي أن يكون نجما معينا من الإساءة من قبل المستخدمين بطريق الخطأ. يمكنك الاحتفاظ بالنجمة محدثة بعدة طرق، بما في ذلك المشغلات والوظائف المجدولة، وما إلى ذلك. يمكن أن تكون سريعة جدا لاحتياجات الإبلاغ وتشغيلها على نفس تثبيت الإنتاج - ربما في حالة منفصلة إذا لم تكن مجرد قاعدة بيانات منفصلة.
على الرغم من أن هذا الحل قد يتطلب منك بشكل فعال أكثر من مضاعفة متطلبات التخزين الخاصة بك، عند مقارنتها بالممارسات الأخرى، قد يكون هناك خيار جيد حقا إذا فهمت بياناتك جيدا ولا تمانع في الحصول على نموذجين - واحد للمعاملات واحدا للتحليل (لاحظ أنك ستبدأ بالفعل في الحصول على هذا الفصل المنطقي هذا على أي حال باستخدام أبسط خيار العرض الأول).
غالبا ما يضاعف بعض المهندسين المعماريين خوادمهم واستخدام نفس النموذج مع نوع من النسخ المتماثل من أجل توفير خادم إعداد التقارير مفهرسة بشكل كبير أو بشكل مختلف. هذا الخادم الثاني لا يؤثر على المعاملات الإنتاجية مع متطلبات الإبلاغ ويمكن الاحتفاظ به حتى الآن بسهولة إلى حد ما. سيكون هناك نموذج واحد فقط، ولكن بالطبع، هذا لديه نفس مشاكل قابلية الاستخدام في السماح للمستخدمين الوصول المخصص إلى النموذج الأساسي فقط، دون تأثير الأداء، لأنهم يحصلون على ملعب خاص بهم.
هناك الكثير من الطرق للجلد هذه القطط. حظا طيبا وفقك الله.
الزبون دائما على حق. ومع ذلك، من المحتمل أن يلقي العميل عند تحويل متطلباتهم إلى دولار والسنة. وبعد سيتطلب جدول 100 عمود الوقت دائمة إضافية لكتابة التعليمات البرمجية التي تقوم بها قاعدة البيانات تلقائيا بالتنفيذ السليم. علاوة على ذلك، هم ستكون تكاليف الدعم أعلى نظرا لأن المزيد من التعليمات البرمجية تعني المزيد من المشاكل وسهولة تصحيح الأخطاء.
سألعب داعية الشيطان هنا وأقول أن كلا الحلول تبدو وكأنها تقريبية سيئة للبيانات الفعلية. هناك سبب لا يميل لغات البرمجة الموجهة للكائنات إلى تنفيذها بأي من نماذج البيانات هذه، وليس لأن أفكار CODD لعام 1970 حول العلاقات كانت النظام المثالي لتخزين وهياكل البيانات الموجهة نحو الكائنات. :-)
تذكر أن SQL تم تصميم SQL في الأصل ككلغة واجهة المستخدم (هذا هو السبب في أنه يبدو بشكل غامض مثل اللغة الإنجليزية وليس على الإطلاق مثل لغات أخرى من هذا العصر: Algol، C، APL، Prolog). الأسباب الوحيدة التي سمعتها لعدم تعريض قاعدة بيانات SQL للمستخدمين اليوم أمن (يمكن أن تؤدي إلى أسفل الخادم!) وسهولة الاستخدام (من يريد كتابة SQL عندما يمكنك النقر فوق النقر؟)، ولكن إذا كان خادمهم وهم تريد، ثم لماذا لا تدعهم؟
بالنظر إلى أن "الجزء الأكبر من النظام يدور حول نوع الوثارة من العلاقة"، فأنا أفكر بجدية في قاعدة بيانات تتيح لي أن تمثل هذا أصليا، سواء postgres. (إذا كان SQL مهم) أو قاعدة بيانات كائن أصلي (والتي هي رائعة للعمل معها، إذا لم تكن بحاجة إلى توافق SQL).
أخيرا، تذكر أن كل قرار هندسي هو مفاضلة. من خلال "التمسك بنادقك" (كما اقترح شخص آخر)، فأنت تقول ضمنا قيمة رغبات المستخدمين الخاصة بك هي صفر. لا تسأل حتى إجابة صحيحة على هذا، لأننا لا نعرف ما يريده المستخدمون القيام به مع بياناتك (أو حتى البيانات الخاصة بك، أو من هم المستخدمون الخاص بك). اذهب أخبرهم لماذا تريد حل العديد من الجداول، ثم أعمل حلا معهم من المقبول لكلا منكما.
لقد نفذت الجدول الميراث ويطلبون ميراث جدول واحد. وبعد كلا التصميمات صالحة في بعض الحالات.
قد ترغب في الحصول على نسخة من مارتن فاولر أنماط تطبيقات تطبيق المؤسسة لقراءة المزيد عن مزايا وعيوب كل تصميم. هذا الكتاب هو إشارة كلاسيكية إلى رف الكتب الخاص بك، في أي حال.
