ترقية Informix - التبديل إلى Oracle أو Sybase أو البقاء مع Informix؟
https://stackoverflow.com/questions/697083
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد قمت سابقًا بنشر سؤال حتى أتمكن من تأكيد إصدارنا الحالي (وإن كان قديمًا) من Informix هنا:
كيف يمكنك التعرف على إصدار Informix على سولاريس؟
(شكرًا لك جوناثان وRET على توضيح ذلك)
نحن بالتأكيد نخطط للترقية ولكننا نناقش أولاً ما إذا كان من الأفضل الانتقال إلى Oracle أو Sybase في الوقت الحالي.ماهي آراؤك حول هذا؟في اعتقادي أنه على الرغم من أن جميع أنظمة RDBM الثلاثة لها تفردها الخاص، إلا أنها يجب أن تغطي جميعها نفس الأرضية بشكل أساسي.فكيف يمكن للمرء أن يقرر ما هي قاعدة البيانات التي سيتم استخدامها؟
المهم هو أنني بحاجة إلى معرفة ما إذا كنا نقوم بترقية Informix (الذي يستخدم حاليًا الإصدار 7.13)، فهل سنحتاج إلى تعديل برامج SQL C المضمنة لدينا؟إذا لم يكن الأمر كذلك، فمن المنطقي جدًا الالتزام بـ Informix.لأننا إذا استخدمنا Sybase/Oracle وما إلى ذلك، فسيكون لدينا الكثير من العمل بين أيدينا لتحديث البرامج الخلفية.
ولكن إذا كان التحول إلى قاعدة بيانات أخرى يمكن أن يوفر عائدًا كبيرًا بالمقارنة، فسنظل نأخذه في الاعتبار.وإنني أتطلع إلى سماع آرائكم.
المحلول
أنا مراقب متحيز (أعمل لدى IBM على Informix) - تعامل مع تعليقاتي بالحذر الواجب.
إذا كانت تطبيقاتك مكتوبة بلغة Informix ESQL/C، فسيتعين عليك إجراء عملية جراحية كبرى لنقلها إلى أنظمة أخرى.ستحتاج إلى تحديد الواجهة البديلة التي ستستخدمها - اختيارك عبر الأنظمة الأساسية (مع لغة C كلغة أساسية) هو ODBC، لكن Oracle توفر OCI وتوفر Sybase TDS كبدائل.
على النقيض من ذلك، مع Informix ESQL/C، ترقية إلى الإصدار الحالي (Informix ClientSDK 3.50، الذي يحتوي على ESQL/C 3.50، والذي يكون أحدث من ESQL/C 6.00 الذي تستخدمه حاليًا) يجب أن يكون غير مؤلم إلا إذا بذلت قصارى جهدك لكتابة تعليمات برمجية سيئة.
حتى مجرد ترحيل البيانات قد يكون مؤلمًا بعض الشيء - ولكن ليس بشكل لا يمكن التغلب عليه.يعتمد التعقيد جزئيًا على أنواع البيانات التي تستخدمها.(يتم ترحيل سلاسل الأحرف بسهولة؛على سبيل المثال، قيم التاريخ والوقت أقل سهولة.) لكن ترحيل التطبيقات سيتطلب الكثير من العمل، كما تقول، إلا إذا كنت تتمتع ببصيرة غير عادية وكتبت طبقة تجريد بيانات جيدة حقًا.
ستكون الترقية إلى Informix SE 7.26 أمرًا سهلاً - احصل على البرنامج، ثم قم بتثبيته، ثم قم بتوجيهه إلى قاعدة البيانات الموجودة لديك.ربما ترغب في إعادة ترجمة برامجك لاستخدام CSDK الأكثر حداثة، ولكن يمكنك القيام بذلك بشكل تدريجي بعناية (قيمتان من INFORMIXDIR، واحدة للتعليمات البرمجية القديمة، وواحدة للتعليمات البرمجية الجديدة).
تتطلب الترقية إلى Informix Dynamic Server (IDS) 11.50 تصدير البيانات (DB-Export) من SE واستيرادها (DB-Import) إلى IDS.سيكون هذا أمرًا بسيطًا جدًا أيضًا، بمجرد تشغيل IDS.يتطلب إعداد IDS وتشغيله جهدًا أكبر من SE، ولكنه ليس بهذه الصعوبة.
من الواضح أن توصيتي هي البقاء مع Informix.القرار لك بالطبع.
مع IDS، هل يتعين علينا إجراء تغييرات على التعليمات البرمجية أو مجرد إعادة الترجمة؟
يرتبط IDS ارتباطًا وثيقًا بـ SE، لكنهما مختلفان.يوفر IDS مجموعة شاملة تقريبًا من وظائف SE.الأماكن التي يمكنني التفكير فيها حيث توجد اختلافات هي في المقام الأول عناصر حالة الحافة:
- يحتوي SE على بناء جملة إضافي لإنشاء جدول لتحديد موقع ملفات C-ISAM لقاعدة البيانات؛لدى IDS مجموعة مختلفة تمامًا من الامتدادات.CREATE TABLE الأساسي هو نفسه (على الرغم من أن IDS يحتوي على أنواع لا تحتوي عليها SE، مثل VARCHAR)، لكن الزينة مختلفة.
- لدى SE إنشاء تدقيق وإسقاط التدقيق بينما لا تقوم IDS بذلك (لديها مرافق تدقيق أخرى).
- لدى SE قاعدة بيانات START وقاعدة بيانات ROLLFORWARD؛IDS لا (يختلف الاسترداد وتسجيل الدخول IDS).
المجال الرئيسي الذي قد يسبب مشاكل هو إدارة المعاملات.قام IDS بإلغاء تسجيل وتسجيل قاعدة بيانات "LOG MODE ANSI"، كما هو الحال مع SE.في IDS، ننصحك باستخدام قاعدة بيانات مسجلة - وستكون هذه توصية قوية.يوفر IDS بيانات ذرية في قاعدة بيانات مسجلة - إما أن يعمل البيان ككل أو يفشل ككل.ومع ذلك، لا تتم كتابة العديد من تطبيقات SE مع وضع المعاملات في الاعتبار.هناك بعض الأشياء التي لا يمكنك القيام بها عند وجود معاملات في قاعدة البيانات، مثل فتح مؤشر للتحديث خارج نطاق المعاملة.هذا هو ما يميل إلى عض التعليمات البرمجية المهاجرة من SE إلى IDS.بالإضافة إلى ذلك، لا يمكنك تأمين جدول إلا في معاملة، ولا يمكنك إلغاء تأمين جدول إلا عن طريق الالتزام أو ROLLBACK.
يعتمد حجم المشكلة على ما كنت تستخدمه في SE وكيفية تصميم البرامج (إذا تم تصميمها بدلاً من تجميعها معًا).قاعدة بيانات IDS غير المسجلة وقاعدة بيانات SE غير المسجلة قريبتان جدًا - ويمكنك الترحيل من واحدة إلى أخرى.لكن IDS يمكنها القيام بأشياء (مثل النسخ المتماثل) فقط عندما يتم تسجيل قواعد البيانات، ويجب أن تهدف إلى استخدام قواعد البيانات المسجلة.
ومع ذلك، يجب أن يكون الترحيل إلى CSDK 3.50 مجرد إعادة ترجمة إلا إذا تمكنت من القيام ببعض الأشياء الفظيعة للغاية.
نصائح أخرى
وشائعات عن وفاة ينفورميكس هي مبالغ فيها إلى حد كبير.
ومع الاستثمار في التعليمات البرمجية المضمنة التي لديك، وبأي ثمن ملصقا توفير التكاليف واضحا أن كان من التحول إلى O العلامة التجارية أو العلامة التجارية S سوف تختفي بسرعة كبيرة في تكاليف إعادة البناء. هذا مجرد حقيقة من حقائق الحياة: رأيت المشاريع حرق 100K + $ على إعادة تطوير لإنقاذ $ 20K كل عام في الترخيص. هذا ليس الأموال التي تنفق بشكل جيد.
وأنت تريد أن يكون للغاية، متأكد جدا من أن التحول من RDBMS كان على وشك تقديم شيء كنت حقا لا يمكن تحقيق العالقة مع ما لديك. لأن خطر (من التجربة المريرة - I حاربه طويل وشاق). هو أنك يمكن أن تنفق ثروة بالدولار والوقت فقط تشغيل على الفور، إن لم يكن إلى الوراء
إذا كنت تريد الذهاب لخطوة الى الوراء والنظر في مشكلتك بشكل كلي، أعتقد أنك ستكون أفضل حالا بكثير تقييم إمكانيات أبنية الجديدة، والمتباعدة، قاعدة بيانات الملحد من مبادلة نموذج واحد جزءا لا يتجزأ من آخر. هذا من شأنه أن يوفر لك مرونة أكبر بكثير على مسار.
وعلى أمل أن يساعد.
ولقد تم دعم ينفورميكس DB لسنوات باستخدام GeneXus. ينفورميكس هو DB كبيرة ولكن ليس هناك الكثير من الأدوات حوله للمساعدة في بناء بطريقة رشيقة. أنا أعرف العديد من المحلات التجارية ينفورميكس التي تستخدم فقط IDE GeneXus لبناء تطبيقات الويب وتطبيقات الهواتف الذكية. إذا لم تكن قد سمعت من GeneXus، التحقق من ذلك.
