سؤال

ترتبط أنماط التصميم عادةً بالتصميم الموجه للكائنات.
هناك أنماط التصميم للإنشاء والبرمجة قواعد البيانات العلائقية?
من المؤكد أن العديد من المشكلات يجب أن يكون لها حلول قابلة لإعادة الاستخدام.

قد تتضمن الأمثلة أنماطًا لتصميم الجدول، والإجراءات المخزنة، والمشغلات، وما إلى ذلك...

هل يوجد مستودع على الإنترنت لمثل هذه الأنماط، على غرار martinfowler.com?


أمثلة على المشاكل التي يمكن للأنماط حلها:

  • تخزين البيانات الهرمية (على سبيل المثال.جدول واحد بنوع مقابل جداول متعددة بمفتاح 1:1 والاختلافات...)
  • تخزين البيانات ببنية متغيرة (على سبيل المثال.الأعمدة العامة مقابل XML مقابل العمود المحدد ...)
  • إلغاء تطبيع البيانات (كيفية القيام بذلك بأقل قدر من التأثير، وما إلى ذلك...)
هل كانت مفيدة؟

المحلول

هناك كتاب في سلسلة توقيع مارتن فاولر يسمى إعادة هيكلة قواعد البيانات.يوفر ذلك قائمة بالتقنيات لإعادة هيكلة قواعد البيانات.لا أستطيع أن أقول أنني سمعت قائمة أنماط قاعدة البيانات كثيرًا.

أود أيضًا أن أوصي بشدة بـ David C.هاي أنماط نماذج البيانات والمتابعة خريطة البيانات الوصفية الذي يعتمد على الأول وهو أكثر طموحًا وإثارة للاهتمام.المقدمة وحدها هي المنيرة.

يعد Len Silverston's Data Model Resource Book Series مكانًا رائعًا للبحث عن بعض نماذج قواعد البيانات المعلبة مسبقًا المجلد 1 يحتوي على نماذج بيانات قابلة للتطبيق عالميًا (الموظفون، الحسابات، الشحن، المشتريات، إلخ)، حجم 2 يحتوي على نماذج بيانات خاصة بالصناعة (المحاسبة، الرعاية الصحية، إلخ)، المجلد 3 يوفر أنماط نموذج البيانات.

أخيرًا، في حين أن هذا الكتاب يدور ظاهريًا حول UML ونمذجة الكائنات، إلا أن بيتر كواد النمذجة بالألوان باستخدام UML يوفر عملية تعتمد على "النموذج الأصلي" لنمذجة الكيان بدءًا من فرضية وجود 4 نماذج أساسية لأي نموذج كائن/بيانات

نصائح أخرى

فيما يلي رابط لرجل نبيل قام بتطوير عدة مئات من مخططات قواعد البيانات المجانية.

http://www.databaseanswers.org/data_models/

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

ثانيًا، تحتوي مجلة SQL Server على عمود عرضي يسمى "The Data Modeler" وهو عمود تعليمي للغاية وغالبًا ما يحتوي على مخططات كاملة لنظام معين.

أنماط التصميم ليست حلولاً قابلة لإعادة الاستخدام بشكل تافه.

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

النمط ليس قابلاً لإعادة الاستخدام بشكل تافه.يمكنك تنفيذ التصميم السفلي الخاص بك باتباع النمط.

تتضمن أنماط التصميم العلائقي أشياء مثل:

  1. علاقات رأس بأطراف (العلاقات الرئيسية-التفاصيل، الأصل-الفرع) باستخدام مفتاح خارجي.

  2. علاقات متعدد إلى متعدد مع جدول الجسر.

  3. تتم إدارة العلاقات الاختيارية من رأس إلى رأس باستخدام القيم الخالية في عمود FK.

  4. مخطط النجمة:البعد والحقيقة، تصميم OLAP.

  5. تصميم OLTP طبيعي بالكامل.

  6. أعمدة بحث مفهرسة متعددة في البعد.

  7. "جدول البحث" الذي يحتوي على PK والوصف وقيمة (قيم) التعليمات البرمجية التي يستخدمها تطبيق واحد أو أكثر.لماذا لديك رمز؟لا أعرف، ولكن عندما يتعين استخدامها، فهذه طريقة لإدارة الرموز.

  8. جدول أحادي.[يسمي البعض هذا النمط المضاد؛إنه نمط، أحيانًا يكون سيئًا، وأحيانًا يكون جيدًا.] هذا جدول يحتوي على الكثير من العناصر المرتبطة مسبقًا والتي تنتهك النموذج العادي الثاني والثالث.

  9. جدول المصفوفة.هذا جدول ينتهك النموذج العادي الأول من خلال وجود مصفوفة أو تسلسل من القيم في الأعمدة.

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

يمكن لمعظم الأشخاص الذين يصممون قواعد البيانات بسهولة أن يقولوا ستة "إنها واحدة أخرى من هؤلاء"؛هذه هي أنماط التصميم التي يستخدمونها بشكل منتظم.

وهذا لا يشمل الأنماط الإدارية والتشغيلية للاستخدام والإدارة.

تحقق من هذه المدونة - مبرمج قواعد البيانات.

ويصف بعض أنماط قاعدة البيانات.

تعتبر كتب جو سيلكو ممتازة في هذا النوع من الأشياء، ولا سيما "SQL for Smarties".لديه بعض الحلول المبتكرة للمشاكل الشائعة، ومعظمها عبارة عن أنماط تصميم قابلة لإعادة الاستخدام.

http://www.celko.com/books.htm

اسألتوم من المحتمل أن يكون المورد الوحيد الأكثر فائدة بشأن أفضل الممارسات في قواعد بيانات Oracle.(عادةً ما أكتب "asktom" باعتبارها الكلمة الأولى في استعلام Google حول موضوع معين)

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

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

بعد سنوات عديدة من تطوير قاعدة البيانات، أستطيع أن أقول إن هناك بعض الأسئلة المحظورة وبعض الأسئلة التي يجب عليك الإجابة عليها قبل البدء:

أسئلة:

  • هل تريد استخدام نظام إدارة قواعد البيانات (DBMS) آخر في المستقبل؟إذا كانت الإجابة بنعم، فلا يتم استخدام عناصر SQL الخاصة لنظام إدارة قواعد البيانات الحالي.إزالة المنطق في التطبيق الخاص بك.

لا تستخدم:

  • المسافات البيضاء في أسماء الجداول وأسماء الأعمدة
  • أحرف غير Ascii في أسماء الجداول والأعمدة
  • ملزمة لحالة صغيرة محددة أو حالة كبيرة.ولا تستخدم أبدًا جدولين أو عمودين يختلفان فقط في الأحرف الصغيرة والأحرف الكبيرة.
  • لا يستخدم كلمات SQL الأساسية لأسماء الجداول أو الأعمدة مثل "FROM" و"BETWEEN" و"DELETE" وما إلى ذلك

التوصيات:

  • استخدم NVARCHAR أو ما يعادله لدعم Unicode، فلن تواجه أي مشاكل مع صفحات الرموز.
  • أعط كل عمود اسمًا فريدًا.وهذا يجعل الأمر أسهل عند الانضمام لتحديد العمود.من الصعب جدًا أن يحتوي كل جدول على عمود "المعرف" أو "الاسم" أو "الوصف".استخدم XyzID وAbcID.
  • استخدم حزمة الموارد أو ما يعادلها لتعبيرات SQL المعقدة.إنه يجعل التبديل إلى نظام إدارة قواعد بيانات آخر أسهل.
  • لا يلقي بقوة على أي نوع من البيانات.لا يمكن أن يحتوي نظام إدارة قواعد بيانات آخر على هذا النوع من البيانات.على سبيل المثال، لا تحتوي أنظمة Oracle على رقم صغير فقط.

آمل أن تكون هذه نقطة انطلاق جيدة.

سؤالك غامض بعض الشيء، ولكن أعتقد UPSERT يمكن اعتباره نمط التصميم.للغات التي لا تنفذ MERGE, عدد من البدائل لحل المشكلة (في حالة وجود صفوف مناسبة، UPDATE;آخر INSERT) يخرج.

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

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

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

راجع للشغل، S.Lott، علاقات واحد إلى متعدد، وعلاقات متعدد إلى متعدد ليست "أنماط".إنها اللبنات الأساسية للنموذج العلائقي.

هذا الكتاب يبدو مثيرا للاهتمام

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top