معالجة صيانة البيانات في قواعد بيانات الكائنات مثل DB4O

Question

شيء واحد لقد وجدت باستمرار مربكة للغاية حول استخدام قاعدة بيانات كائن مثل DB4O. هو كيف من المفترض أن تتعامل مع الهاجرات المعقدة التي عادة ما يتم التعامل معها بواسطة SQL / PL-SQL.

على سبيل المثال، تخيل أن لديك جدول في قاعدة بيانات علائقية تسمى My_Users. في الأصل كان لديك عمود باسم "Full_name"، الآن أن البرنامج الخاص بك في V2، ترغب في إزالة هذا العمود، قم بتقسيم الأسماء الكاملة على مساحة فارغة ووضع الجزء الأول في عمود باسم "first_name" والثاني في العمود اسمه last_name. في SQL، سألتزم ببساطة أعمدة "first_name" و "second_name" ثم قم بإزالة العمود الأصلي باسم "Full_Name".

كيف يمكنني القيام بذلك في شيء مثل DB4O؟ هل أكتب برنامجا Java البرامج النصية التي تبحث عن كافة كائنات user.class، إعداد Full_Name إلى NULL أثناء الإعداد First_name و Last_name؟ عندما أفعل My Next SVN الالتزام، فلن يكون هناك مجال / حبة الفاصوليا المقابلة full_name، هل هذه مشكلة؟ يبدو أنه على الرغم من استخدامه في تطبيق الإنتاج حيث يتغير "المخطط" الخاص بي، فأنا أرغب في كتابة برنامج نصي لترحيل البيانات من الإصدار X إلى الإصدار X + 1 ثم في الإصدار X + 2 قم بإزالة الخصائص التي أحاولها تخلص من الإصدار X + 1 لأنني لا أستطيع كتابة برنامج نصي جافا لتعديل الخصائص التي لم تعد جزءا من النوع الخاص بي.

يبدو أن جزءا من المشكلة هو أن RDBMS يحل الكائن الذي تشير إليه بناء على اسم بسيط يستند إلى سلسلة غير حساسة للحالة، بلغة مثل Java Cuting أكثر تعقيدا من هذا، لا يمكنك الرجوع إلى خاصية إذا كان Getter إذا / setter / field ليس عضوا في الفصل الذي تم تحميله في وقت التشغيل حتى تحتاج أساسا إلى إصدارات 2 من التعليمات البرمجية الخاصة بك في نفس البرنامج النصي (HMM، صوت الكلاس المخصصين مثل الألم)، ولدي الإصدار الجديد من الفصول الدراسية المخزنة حزمة أخرى (يبدو فوضوي)، أو استخدم الإصدار X + 1 X + 2 إستراتيجية المذكورة (تتطلب الكثير من التخطيط). ربما هناك بعض الحل الواضح لم أتم جمعها من مستندات DB4O.

أيه أفكار؟ نأمل أن هذا يجعل بعض الشعور.

Answer 1

أولا، يعالج DB4O "بسيط" سيناريوهات مثل إضافة أو إزالة حقل تلقائيا. وبعد عند إضافة الحقل، يكون لجميع الكائن الموجود القيمة الافتراضية المخزنة. عند إزالة حقل، لا تزال بيانات الكائن الموجود في قاعدة البيانات ويمكنك الوصول إليها. إعادة تسمية مجال إلخ مكالمات "Refactoring" الخاصة.

الآن السيناريو الخاص بك كنت تفعل شيئا مثل هذا:

1. أزل الحقل "full_name"، أضف الحقول الجديدة "first_name" و "second_name"
2. تكرر كل شيء "العناوين"
3. الوصول إلى الحقل القديم عبر "storedclass'-API
4. الانقسام والتغيير والتحديث وغيرها القيمة. اضبط القيم الجديدة في الحقل الجديد وتخزين الكائن.

دعونا نفترض أن لدينا طبقة العنوان. تم إزالة حقل "Full_name". الآن لن ننسخها إلى "الاسم الأول" و "اللقب". ثم يمكن أن يذهب مثل هذا (Java):

    ObjectSet<Address> addresses = db.query(Address.class);
    StoredField metaInfoOfField = db.ext().storedClass(Address.class).storedField("full_name", String.class);
    for (Address address : addresses) {
        String fullName = (String)metaInfoOfField.get(address);
        String[] splitName = fullName.split(" ");
        address.setFirstname(splitName[0]);
        address.setSurname(splitName[1]);
        db.store(address);
    }

كما اقترحت، سوف تكتب رمز الترحيل لكل إصدار من الإصدار. إنه حقل ليس جزءا من فصلك بعد الآن، يجب عليك الوصول إليه مع "API" API أعلاه.

يمكنك الحصول على قائمة جميع الفئات المخزنة مع ObjectContainer.ext().storedClasses(). وبعد مع StoredClass.getStoredFields() يمكنك الحصول على قائمة بجميع مجالات المتاجر، لا يوجد ماتثر غير موجود في فصلك. إذا لم تعد فئة موجودة بعد الآن، فلا يزال بإمكانك الحصول على الكائنات والوصول إليها عبر فئة "Genericobject".

تحديث: لسيناريوهات المعجب حيث تحتاج قاعدة البيانات إلى ترحيلها على خطوات متعددة الإصدار.

على سبيل المثال، في الإصدار v3 يبدو كائن العنوان مختلفا تماما. لذا فإن "النص النصي للترحيل" ل V1 إلى V2 لم يحصل على الحقول بعد الآن (الاسم الأول وسارينام في مثالي). أعتقد أن هناك إمكانيات متعددة للتعامل مع هذا.

1. (على افتراض جافا لهذه الفكرة. بالتأكيد هناك ما يعادلها .NET). يمكنك جعل خطوة الترحيل groovy- script.. وبعد لذلك كل من كل برنامج نصي لا يتداخل مع آخر. ثم تحدد "الطبقات" الفئات اللازمة للهجرة هناك. لذلك كل هجرة لديها فصول الهجرة الخاصة بها. مع اسماء مستعارة يمكنك ربط فصول الترحيل المزخرفة بك إلى فئات جافا الفعلية.
2. إنشاء فئات إعادة المسافات السيناريوهات المعقدة. ربط أيضا هذه الفئات مع اسماء مستعارة.

Answer 2

أنا آخذ قليلا من النار البرية هنا، لأنني لم أعد عدلا الكثير من البيانات في حياتي.

أنت تقوم بإجراء مقارنة غريبة: إذا كنت ترغب في "الترحيل الساخن" DB، فمن المحتمل أن تضطر إلى القيام بذلك x+1, x+2 نهج الإصدار الذي وصفته، لكنني لا أعرف حقا - أنا لا أعرف كيفية القيام بذلك مع SQL إما لأنني لست خبير DB.

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

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

في SQL، سألتزم ببساطة أعمدة "الاسم الأول" و "second_name"

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

للقيام بذلك، يجب عليك كتابة التعليمات البرمجية أيضا.

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