نصائح حول إعادة بناء مخطط قاعدة بيانات قديم [مغلق]

Question

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

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

---

المثال الخاص بي:

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

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

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

Answer 1

فيما يلي كتالوج كامل لإعادة هيكلة قاعدة البيانات:

http://databaserefactoring.com/

Answer 2

هذا أمر صعب للغاية للتغلب عليه؛هناك خياران سريعان بعد إعادة هيكلة قاعدة البيانات هما:

قم بإنشاء عروض تتطابق مع المخطط الأصلي ولكنها تسحب من المخطط الجديد؛قد تحتاج إلى مشغلات هنا حتى يمكن التعامل مع أي تحديثات لطرق العرض.

قم بإنشاء المخطط الجديد وقم بوضع المشغلات على كل جانب للحفاظ على الجانب الآخر.

Answer 3

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

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

Answer 4

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

ثم تصبح إيصالاتك وشحناتك مشاهدات.

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

Answer 5

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

نأمل ألا يكون لدى أي منهم استعلامات "تحديد *".إذا فعلوا ذلك، فاستخدم 'sp_help tablename' للحصول على القائمة الكاملة للأعمدة، وانسخها واستبدل كل * بقائمة الأعمدة الكاملة، فقط للتأكد من عدم كسر رمز العميل.

أوصي بإجراء التغييرات تدريجيًا وإجراء الكثير من اختبارات التكامل.من الصعب إجراء عملية إعادة تصميم كبيرة دون إدخال بعض الأخطاء.

Answer 6

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

Answer 7

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

Answer 8

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

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