هل من الممكن استخدام Tibero بدلاً من Oracle. وهل من الضروري

في هذه المقالة ، سأخبرك كيف فكرت بجدية في بديل لـ Oracle. ولكن ماذا عن Postgre ، تقول؟ نعم ، ولكن هناك فروق دقيقة. سنتناول أولاً السؤال "لماذا Oracle؟"
منطق الأعمال في قاعدة البيانات الخاصة بنا. يكتب توم كايت في كتاب أوراكل للمحترفين

عند تطوير تطبيقات قواعد البيانات ، أستخدم شعارًا بسيطًا للغاية:

إن أمكن ، افعل ذلك بعبارة SQL واحدة ؛
إذا كان لا يمكن القيام بذلك باستخدام عبارة SQL واحدة ، فقم بذلك في PL / SQL ؛
إذا كان لا يمكن القيام بذلك في PL / SQL ، فحاول استخدام إجراء Java المخزن ؛
إذا كان لا يمكن القيام بذلك في Java ، فقم بذلك كإجراء خارجي في C ؛
إذا كان هذا لا يمكن تنفيذه كإجراء خارجي في C ، فأنت بحاجة إلى التفكير بجدية في سبب القيام بذلك على الإطلاق ...

وفي تصميم النظام ، أتبع هذه القاعدة. أنواع الكائنات في Oracle مرضية بشكل خاص ؛ بمساعدتها ، يتم تنفيذ منطق الأعمال المعقدة بشكل جميل ومريح وفقًا لجميع شرائع OOP.

أوراكل باهظة الثمن. شرائه وعدم استخدام كل ما هو فيه سيكون خطأ.
ومع ذلك ، هناك دائمًا عامل الفريق والكفاءات. إذا كان فريقك يعمل على تطوير كل شيء في Oracle لمدة عشر سنوات ، فقد يكون إصدار Postgre مؤلمًا.

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

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

وصف التجربة

يقول ممثلو TMaxSoft أن Tibero متوافق تقريبًا مع Oracle بنسبة 100٪ ، وهناك فائدة لترحيل قاعدة البيانات. قررت أخذ قاعدة المنتج الخاصة بي ، باستخدام منطق الأعمال في Oracle ، باستخدام كل سحر OOP في PL \ SQL ، ونقله إلى Tibero. في هذا المنشور ، لا نعتبر ترحيل البيانات نفسها ، وهو أقل إثارة للاهتمام ، ولم أحاول الترحيل الكامل حتى الآن.

المهمة هي:

1. جداول التحويل.
2. نقل الفهارس ، المفاتيح ، إلخ.
3. نقل الحزم والمحفزات.
4. نقل أنواع الكائنات.

لكن أولاً ، دعنا نتعامل مع الأدوات.

الأدوات

جوجل لا يعرف سوى القليل عن Tibero. لقد قمنا بتنزيل قاعدة البيانات نفسها في شكل آلة افتراضية تم نشر كل شيء عليها بالفعل. هناك أداتان فقط: أداة مساعدة لترحيل T-UP ، و IDE لـ DBA ومطور tbAdmin. كل شيء يتم في جافا ، يعمل في أي مكان ، نظريا.

يبدو T-UP شيئًا مثل هذا:


النافذة الرئيسية: اتصالات قاعدة البيانات.


إذا قمت بالنقر فوق "خيارات" ، يمكنك تكوين شيء ما.


الأهم من ذلك ، يمكنك تحديد أنواع الكائنات المراد ترحيلها.

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

الأداة الثانية هي Tibero Admin IDE. يمكن تنزيله من موقع TMaxSoft إذا قمت بالتسجيل هناك أولاً. يمكنك أيضًا الحصول على ترخيص تجريبي هناك.


يبدو Tibero Admin مثل IDE القديم النموذجي

اعتدت على أداة المطور PL / SQL الممتازة من Allround Automations. في Tibero Admin ، انسى المطالبات السياقية ، لن يظهر شيء على الشاشة بعد النقر على "النقطة" ، لن يلحق لك أسماء الجداول والكائنات. فقط اكتب الرمز ، أيها المبرمجون. المساعدة والتوثيق؟ لا. هناك وثائق على نظام إدارة قواعد البيانات (DBMS) على موقع الشركة المصنعة ، وهذا مثير للاهتمام ... بدون بحث. لم يتم العثور على وثائق IDE. ومع ذلك ، لا يوجد شيء معقد. كانت هناك مشاكل في التفويض - اتضح أن المستخدم يحتاج إلى منح حقوق DBA للانتقال إلى tbAdmin. ومثير للاهتمام مع الموانئ ، 8630 هو ل SYS ، لجميع 8629 الأخرى .

البق IDE. من وقت لآخر ، عندما تطلق في مكان ما ، يطير مؤشر الرسالة خارج الحدود ، رسالة مثل java.lang.Exception: الالتزام الناجح مخيف جدًا. من الضروري مراعاة أنواع مختلفة من نوافذ SQL و PSM: في الأول ، من غير المحتمل أن تقوم بتجميع كود البرنامج ، وفي الثانية ، لن تقوم بتنفيذ الطلب. بعد PL / SQL Developer - مظهر بائس لليد اليسرى ...

الوصول إلى التجربة.

ترحيل الجدول

نختار المخطط في T-UP ، وننقر على الترحيل ، ونحدد أولاً "الجداول" في الخيارات وتبدأ عملية النقل. واجهت مشكلتين.

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

بالإضافة إلى الجداول ذات قيم التاريخ الافتراضية من النوع '31 .12.2019 '. في إعدادات أوراكل ، لدينا هذا التنسيق المسجل ، لأن Tibero يساعد

alter session set nls_date_format='DD.MM.YYYY'; 

ولكن لا يوجد مكان لـ T-UP للقيام بذلك. نصح الزملاء من TMaxSoft بتعيين المتغير TB_NLS_DATE_FORMAT = "DD.MM.YYYY" ، ولكنه لم يساعدني شخصيًا. ربما فعلت شيئا خاطئا. اضطررت إلى إنشاء جداول بهذه المعلمات يدويًا ، وليس هناك الكثير منها.

نتيجة الخطوة الأولى: نقل بنية الجدول من Oracle إلى Tibero يعمل بشكل جيد.

المفاتيح والفهارس.

نختار مربعات الاختيار INDEX و CONSTRAINT في T-UP وإلى الأمام. نشأت مشاكل مع CHECK بسبب نفس الموقف مع التاريخ. بشكل عام ، تم إنشاء الفهارس والمفاتيح الأساسية والشيكات. ولكن لم أجد مفاتيح أجنبية في قاعدة البيانات التي تم إنشاؤها حديثًا. وينتهي ترحيل الثوابت في سجل T-UP برسالة "فشل الترحيل: java.lang.NullPointerException". صدفة؟ لا أعتقد ذلك ...

الحزم والمحفزات.

في المحفزات ليس لدي أي شيء معقد ، تم إنشاؤها بشكل مثالي. صحيح ، لم أتحقق من كيفية عملهم ، وستكون هذه قصة منفصلة.

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

من بساطة: لا يوجد في جيش تيبيرو كلمة جديدة . ال o: = بناء جديد t_my_type () لن يتم ترجمة. في Oracle ، هذا صحيح ، وليس إلزاميًا ، لكنني كتبت دائمًا لسبب ما. اضطررت إلى الحذف.

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

من المحدد. حصلت على FORALL غريب في قاعدة البيانات الخاصة بي ، ومع ذلك ، يعمل.

 --     PROCEDURE save_tar_test AS TYPE number_table IS TABLE OF NUMBER INDEX BY BINARY_INTEGER; TYPE date_table IS TABLE OF DATE INDEX BY BINARY_INTEGER; TYPE varchar50_table IS TABLE OF VARCHAR2(50) INDEX BY BINARY_INTEGER; TYPE char1_table IS TABLE OF CHAR(1) INDEX BY BINARY_INTEGER; TYPE t_tar_det_out_upd_rec_test IS RECORD ( --   cmr_tar_det_id number_table, in_stamp date_table, err_code_id number_table ); tdou_rec t_tar_det_out_upd_rec_test; BEGIN --   ,  tdou_rec  :      Oracle FORALL j IN 1 .. tdou_rec.cmr_tar_det_id.COUNT UPDATE cmr_tar_det dd SET err_code_id = tdou_rec.err_code_id(j) WHERE dd.cmr_tar_det_id = tdou_rec.cmr_tar_det_id(j) AND in_stamp = tdou_rec.in_stamp(j); END; 

يقول Tibero "يجب أن تحتوي عبارة dml على معلمة مجمعة ia forall close" . وأنا أتفهم ذلك بعمق ، ولكن يجب إعادة تصميم هذا الرمز في دورة منتظمة.

الوضع مع الجداول التي تحتوي على الأشياء أسوأ.

 CREATE OR REPLACE TYPE S1.TYPE_PAY_HIST AS OBJECT ( pay_status_id NUMBER(1), stamp DATE ); CREATE OR REPLACE TYPE S1.TABLE_PAY_HIST AS VARRAY(10) OF type_pay_hist; create table S2.RECEIPT ( receipt_id NUMBER(8) not null, pay_sum NUMBER(12,2) not null, receipt_hist S1.TABLE_PAY_HIST ); FUNCTION receipt_status_change(p_cmr_receipt_id NUMBER, p_new_status NUMBER) RETURN NUMBER AS l_receipt_hist s1.table_pay_hist; l_type_pay_hist s1.type_pay_hist; l_status NUMBER; BEGIN BEGIN SELECT receipt_hist INTO l_receipt_hist FROM receipt p WHERE p.receipt_id = p_cmr_receipt_id FOR UPDATE; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN c_err_not_find_status; END; ... END; 

لدينا خطأ في الترجمة ، اكتب الخطأ.

اقترح الرجال من TMaxSoft هذا الإصدار من التعليمات البرمجية:

 create or replace FUNCTION .... AS l_receipt_hist table_pay_hist; l_type_pay_hist type_pay_hist; l_status NUMBER; cmr_receipt_row cmr_receipt%rowtype; BEGIN BEGIN SELECT * INTO cmr_receipt_row FROM cmr_receipt p WHERE p.cmr_receipt_id = p_cmr_receipt_id FOR UPDATE; SELECT TYPE_PAY_HIST(r.pay_status_id,r.stamp) bulk collect INTO l_receipt_hist FROM cmr_receipt p,table(p.receipt_hist) r WHERE p.cmr_receipt_id = p_cmr_receipt_id; EXCEPTION WHEN NO_DATA_FOUND THEN dbms_output.put_line('NO_DATA_FOUND'); RETURN null;--c_err_not_find_status; END; ... END; 

العمل ربما يعمل. ولكن ليس مناسبًا جدًا ، وعليك إعادة الرمز.

يتم تجميع الباقي بشكل طبيعي ، باستثناء أشياء محددة مثل SDO_GEOM. وبالمناسبة ، Tibero لديه نظير. لم تصل يديه بعد دراسته.

أنواع

في أحد المشاريع ، نستخدم قوة OOP بواسطة Oracle hollow.
كان السؤال الأكثر إثارة لتيبرو حول هذا الموضوع.

نقوم بإنشاء نوع معين ، وهو أساسي لمجموعة من الأنواع الأخرى.

 CREATE OR REPLACE TYPE t_tar_object AS OBJECT ( id NUMBER(12), smth NUMBER(12), CONSTRUCTOR FUNCTION t_tar_object RETURN SELF AS RESULT, MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, MEMBER FUNCTION inside(o t_tar_object) RETURN NUMBER, MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL; --  CREATE OR REPLACE TYPE BODY t_tar_object AS CONSTRUCTOR FUNCTION t_tar_object RETURN SELF AS RESULT AS BEGIN RETURN; END; MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER AS BEGIN RETURN id; END; MEMBER FUNCTION clone RETURN t_tar_object AS BEGIN RETURN NULL ; END; END; 

والآن نحاول خلق وريث جدير به.

 CREATE OR REPLACE TYPE t_tar_service UNDER t_tar_object ( is_virtual NUMBER(1), CONSTRUCTOR FUNCTION t_tar_service (p_serv_obj t_tar_object, p_main_id NUMBER, p_pack_id NUMBER) RETURN SELF AS RESULT, OVERRIDING MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, OVERRIDING MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL; 

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

 declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target; -- dbms_output.put_line (i1)   . --      ,  ,     i1   -- if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

يبدو أننا لم نترك خيارًا للبرنامج ، بغض النظر عن القيمة التي يأخذها المتغير i1 ، يجب أن يظهر شيء ما في الإخراج. لكن ... لا شيء يظهر!


تذكرت على الفور فيلم عظيم

هذا الغريب لا ينتهي عند هذا الحد. جعل التجربة أسوأ

 declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target; --  ,      -    i1 := 2; if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

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

تجربة التحكم ، اختبر نفسك من أجل الجنون:

 declare o1 t_tar_object; i1 number ; begin o1 := t_tar_object; o1.id := 1; --i1 := o1.target;    i1 := 2; if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

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

ليس هناك جدوى من الحديث أكثر عن OOP في Tibero. مثل ، في الواقع ، OOP في Tibero. بعد ذلك ، يطرح سؤال آخر: ومدونة الإجراءات والوظائف التي تم تجميعها - هل تعمل بشكل صحيح؟ لا اعرف حتى الان. هاجرت كمية كبيرة من التعليمات البرمجية وتجميعها. بالنسبة لمشروع لا يحتوي على أنواع التمارين المذكورة أعلاه ، فهذا نجاح واضح. لكن اختبار التنفيذ الصحيح للكود هو مهمة خطيرة. وبصراحة ، لم أكن أتوقع أن ألتقي بها. لن أكون مستعدًا للقول ما إذا كان لدي مشروع على نظام إدارة قواعد البيانات (DBMS) هذا. ولكن إذا حدث ذلك ، فسيتم التطوير على Oracle ، باستخدام أدوات ملائمة عادية ، وبالانتقال المنتظم إلى Tibero. كتابة التعليمات البرمجية في IDE بدون مطالبات سياقية مع وجود أخطاء دورية للواجهة نفسها متعة أقل من المتوسط.

الاستنتاجات

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

هل من المنطقي استخدام Tibero المجاني تقريبًا الذي يتم تقديمه الآن؟ ربما نعم. يقولون أنه عند دفع تكلفة الدعم الفني (99000 روبل سنويًا للمقبس) ، يُسمح باستخدام هذه القاعدة في المشاريع التجارية. إذا كان لديك فريق من علماء الفلك ، وتحتاج إلى إنشاء ونشر شيء ليس صعبًا على الخادم الخاص بك ، ولكنه أرخص وأسرع - وهو خيار مثير للاهتمام. لا يزال بإمكانك لعب بطاقة العقوبات ، وإخبار العملاء المضطربين أن كوريا ليست الولايات المتحدة.

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

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

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

ملاحظة

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