هل تستخدم نمط DTO لمزامنة مخططين؟

Question

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

أخطط لاستخدام نمط DTO لتوحيد تمثيل الكائنات:

DB ----> DTO ----> رسم الخرائط (الحروف / المستوطنون) ----> DTO ----> DB

أعتقد أنها فكرة أفضل من المزامنة فعليًا باستخدام استعلام SQL على كل جانب، وأستخدم السبات لإضافة التجريد ومزامنة الكائن.

هل تعتقد أنها فكرة جيدة؟

Answer 1

قد يكون القيام بذلك باستخدام ORM أبطأ من حيث الحجم مقارنة ببرنامج نصي SQL جيد الصياغة.ذلك يعتمد على حجم قاعدة البيانات.

يحرر

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

تتمتع SQL أيضًا بميزة أن الجميع يعرفون كيفية تشغيل البرنامج النصي، ولكن لن يعرف الجميع كيفية تشغيل الأداة المخصصة (هذه مشكلة واجهتها عمليًا إذا تم تشغيل الترحيل بالفعل بواسطة شخص آخر).

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

2. للمخططات مع اختلافات كبيرة, ، مع البيانات المنظمة في جداول مختلفة أو منطق معقد لتعيين بعض القيمة من مخطط إلى آخر، فإن الأداة المخصصة قد تكون منطقية.من المحتمل أن يكون الجهد الأولي لكتابة الأداة أكثر أهمية، ولكنه يمكن أن يكون أحد الأصول بمجرد إنشائها.

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

1. يمكن بالفعل أن يصبح برنامج SQL النصي "فوضويًا" في ظل هذه الظروف.إذا كانت لديك مثل هذه القيود، فستتطلب SQL مهارات متقدمة وسيكون من الصعب استخدامها وصيانتها.

2. يمكن أن تتطور الأداة المخصصة إلى ETL صغير مع القدرة على تقسيم العمل إلى معاملات صغيرة، وإدارة الأخطاء وتسجيلها بشكل جيد، وما إلى ذلك.يعد هذا مزيدًا من العمل، ويمكن أن يؤدي إلى كونه مشروعًا مخصصًا.

القرار لك.

Answer 2

ونيس المرجع أعلاه للدليل هتشكوك.

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

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

وتيم

Answer 3

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