it-swarm.asia

هل يجب عليك تصميم قاعدة البيانات قبل كتابة رمز التطبيق؟

ما هي الطريقة الأسهل والأكثر فعالية لتصميم قاعدة بيانات؟ من وجهة نظري ، هناك خياران لتصميم متجر بيانات التطبيق:

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

في تجربتك ، ما هي الطريقة الأكثر إنتاجية وكفاءة؟

57
Thomas Stringer

بالإضافة إلى إجابات أخرى ...

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

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

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

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

42
gbn

سيكون من الصعب عليك العثور على أي قسم برامج حديث لا يعمل بأحد أنواع Agile. وبالمقارنة ، فإن DBA عالقة في العصور المظلمة ، مع هذا النوع من التفكير بأن إجابة @ RobPaller لا تزال تحتوي على مكان شائع.

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

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

أعتقد أن هذا يضع تصويتي مع الخيار 2 وأظن أنني قد أجد نفسي واقفاً في البرد على هذا الخيار!

27
Mark Storey-Smith

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

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

  1. Scope creep - أنت تسمح بتقديم متطلبات جديدة في وقت غير مناسب.
  2. متطلبات الأعمال غير الكافية - لم يقم مصمم (نماذج) البيانات (أو محللو النظام) بترجمة المتطلبات من محللي الأعمال بشكل كافٍ. نتج عن هذا نموذج بيانات غير مكتمل أو غير صحيح لدعم متطلبات التطبيق الخاص بك.

ومع ذلك ، بمجرد تحويل التطبيق إلى الإنتاج ، ليس من غير المألوف العودة وإجراء تغييرات تكرارية على نموذج البيانات لدعم التطور الطبيعي للتطبيق أو العمليات التجارية الأساسية.

أتمنى أن يساعدك هذا.

12
RobPaller

كان لدي ترف تصميم العديد من قواعد البيانات ذات التعقيد المتوسط ​​، وكلها مستخدمة في الأعمال التجارية ، مع واجهات أمامية مختلفة بما في ذلك الويب والوصول و C #.

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

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

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

أنا جيد في ما أفعله. ولكن هناك شخص واحد فقط أقوم بذلك في بيئة "لا تحقق التنمية".

ومع ذلك ، فإنني أتحسن في اكتشاف قواعد العمل. وأرى نوعًا من الخيار الثالث:

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

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

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

في رأيي ، هذا فوز كبير.

11
ErikE

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

هذا يأخذ قدر معين من انضباط المشروع. قم بتطبيق التطبيع بدقة (Boyce-Codd/Fifth Normal Form) في كل مرة تقوم فيها بتغيير قاعدة البيانات بحيث تحافظ على الجودة ولا ينتهي بك الأمر بنموذج مخصص وغير متناسق. كن صارمًا قدر الإمكان مع قواعد العمل وقيود قاعدة البيانات المصاحبة. إذا كنت تشك في أنه من الأفضل فرض قيد مبكر - يمكنك دائمًا أخراجه لاحقًا. كن ذكيًا في الترتيب الذي تقوم فيه بتنفيذ مكونات معمارية لتقليل الديون الفنية. احصل على مجموعة جيدة من إرشادات تصميم قاعدة البيانات التي يشتريها جميع فريق التطوير.

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

10
nvogel

في عالم الهندسة المعمارية ، تم صياغة العبارة "Form Follows Function" وتم لاحقًا الالتزام بها عند إنشاء المباني الشاهقة. وينطبق الشيء نفسه على البنية التحتية DB وتطوير التطبيقات.

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

لسوء الحظ ، ستلتقط بعض متاجر المطورين شيئًا مثل memcached ، وتحمله بالبيانات في RAM (وبالتالي تعاملها مثل قناة بيانات) ، ولديها قاعدة بيانات ، مثل MySQL أو PostgreSQL ، تتصرف ببساطة مثل وحدة تخزين البيانات.

يجب أن يكون الحافز لاستخدام قاعدة بيانات هو النظر إليها بشكل صحيح: كدليل قواعد بيانات RDBMS. نعم ، a Relational نظام إدارة قواعد البيانات. عند استخدام RDBMS ، يجب ألا يكون هدفك مقدمًا هو إنشاء جداول للتخزين فحسب ، ولكن أيضًا لاسترجاعها. يجب أن تكون العلاقات بين الجداول على غرار البيانات التي تريد رؤيتها وكيف يتم تقديمها. يجب أن يعتمد ذلك على تماسك البيانات وتكاملها جنبًا إلى جنب مع قواعد العمل المعروفة. يمكن ترميز قواعد العمل هذه في تطبيقك (Perl ، Python ، Ruby ، ​​Java ، إلخ) أو في قاعدة البيانات .

استنتاج

سأختار بالتأكيد الخيار 1. يتطلب التخطيط السليم ، ونمذجة البيانات ، وتحليل البيانات الجارية. ومع ذلك ، يجب أن يقلل هذا من تغييرات قاعدة البيانات على المدى الطويل.

9
RolandoMySQLDBA

أعتقد أنه يجب القيام بذلك قبل وجود أي رمز فعلي للتطبيق ، ولكن ليس قبل تصميم التطبيق.

سير العمل النموذجي ، إذا كان العمل بمفرده هو:

  1. تحديد ما يحتاج التطبيق للقيام به
  2. انظر لمعرفة ما إذا كان يمكن تقسيم أي من المهام للمكونات القابلة لإعادة الاستخدام
  3. حدد كيف تحتاج كل مهمة للتفاعل مع تخزين البيانات - ما نوع الأسئلة التي ستطرحها على البيانات ، وكم مرة ستكتب ، وما إلى ذلك.
  4. صمم قاعدة البيانات بحيث تكون قادرة على الإجابة على جميع الأسئلة التي نحتاج إلى طرحها عليها ، ويجب أن تعمل بشكل جيد في معظم المهام المتكررة.
  5. اكتب الطلب.

نظرًا لأنني أعمل كثيرًا كجزء من فريق ، ونحن متناثرون جغرافيًا (وعبر المناطق الزمنية) ، فإننا نميل إلى عقد اجتماع انطلاق أولي:

  1. تحديد ما يحتاج التطبيق للقيام به.
  2. حدد أين توجد نقاط جيدة لتقسيم التطبيق إلى مكونات قائمة بذاتها
  3. حدد كيف سيحتاج كل مكون للتفاعل مع الآخرين.
  4. وافق على API لكل تفاعلات.

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

9
Joe

لدي في الاعتبار القاعدة التالية: "يمكنك فقط الحصول على قاعدة البيانات المعلومات التي لديك البيانات لتوليدها". لذا ، أقوم أولاً بتصميم قاعدة البيانات لاحقًا الرمز.

لماذا ا؟ بغض النظر عن علم القياس/اللغة/مجموعة الأدوات التي أستخدمها ، إذا تم تصميم جميع البيانات ذات الصلة وتخزينها بشكل جيد في DB يمكنني استعادتها. بغض النظر عما إذا كان في C #/دلفي/FORTRAN/COBOL/Assembly/VBA أو تقارير Crystal ؛ OO مصمم أو حدث/بيانات/أي شيء مدفوع ؛ رشيق أو شلال. إذا كانت البيانات موجودة ، يمكنني استردادها إذا كانت الأدوات التي أستخدمها يمكن الاتصال بقاعدة البيانات. يمكنني إنشاء تقارير المبيعات إذا كان بإمكاني تحديد الطلبات الخاصة بإيرادات الربع - حتى لو كان عليّ كتابتها بايت بايت في التجميع.

إذا لم تكن البيانات ذات الصلة موجودة أو حتى إذا كانت موجودة ولكن (غير) منظمة بطريقة لا يمكنني استرداد المعلومات التي أحتاجها - كيف يمكنني ترميزها؟

8
Fabricio Araujo

كالعادة ، يعتمد ذلك ؛)

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

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

7
A-K