Pada artikel ini, saya akan memberi tahu Anda betapa saya serius memikirkan alternatif untuk Oracle. Tapi bagaimana dengan Postgre, katamu? Ya, tapi ada nuansa. Pertama kita akan berurusan dengan pertanyaan "Mengapa Oracle?"
Logika bisnis dalam database kami. Dalam buku Oracle untuk para profesional, Tom Kite menulis
Saat mengembangkan aplikasi basis data, saya menggunakan mantra yang sangat sederhana:
jika memungkinkan, lakukan dengan satu pernyataan SQL;
jika ini tidak dapat dilakukan dengan pernyataan SQL tunggal, lakukan dalam PL / SQL;
jika ini tidak dapat dilakukan dalam PL / SQL, coba gunakan prosedur tersimpan Java;
jika ini tidak dapat dilakukan di Jawa, lakukan sebagai prosedur eksternal dalam C;
jika ini tidak dapat diimplementasikan sebagai prosedur eksternal dalam C, Anda harus serius memikirkan mengapa ini dilakukan sama sekali ...
dan dalam desain sistem, saya mengikuti aturan ini. Jenis objek dalam Oracle sangat menyenangkan, dengan bantuannya, logika bisnis yang kompleks indah dan mudah diimplementasikan sesuai dengan semua kanon OOP.
Oracle itu mahal. Membeli dan tidak menggunakan semua yang ada di dalamnya akan menjadi kesalahan.
Namun, selalu ada faktor tim dan kompetensi. Jika tim Anda telah mengembangkan segalanya di Oracle selama sepuluh tahun, melepaskan Postgre bisa sangat menyakitkan.
Oracle itu mahal. Begitu mahal sehingga Anda dapat menulisnya beberapa kali, dan tidak memikirkan perlunya Oracle dalam proyek baru akan menjadi kesalahan.
Beberapa kali saya menemukan publikasi tentang produk Tibero Korea, yang konon dibuat untuk menggantikan Oracle. Dan sekarang mereka memiliki daya tarik kemurahan hati yang belum pernah terjadi sebelumnya - Lisensi standar didistribusikan untuk pengembang hampir gratis, untuk satu dolar untuk soket. Jadi, kami mengerti: apa yang dapat ditawarkan orang Korea saat ini. Bagaimanapun, dengan mobil, mereka sudah (hampir) berhasil!
Deskripsi percobaan
Perwakilan TMaxSoft mengatakan bahwa Tibero hampir 100% kompatibel dengan Oracle, dan ada utilitas untuk migrasi basis data. Saya memutuskan untuk mengambil basis produk saya, dengan logika bisnis di Oracle, menggunakan semua pesona OOP di PL \ SQL, dan mentransfernya ke Tibero. Dalam publikasi ini, kami tidak mempertimbangkan migrasi data itu sendiri, itu kurang menarik, dan saya belum mencoba migrasi penuh.
Tugasnya adalah ini:
1. Tabel transfer.
2. Transfer indeks, kunci, dll.
3. Transfer paket dan pemicu.
4. Transfer jenis objek.
Tapi pertama-tama, mari kita berurusan dengan alat.
Alat-alatnya
Google tahu sedikit tentang Tibero. Kami mengunduh database itu sendiri dalam bentuk mesin virtual di mana semuanya telah digunakan. Hanya ada dua alat: utilitas untuk memigrasi T-UP, dan IDE untuk DBA dan pengembang tbAdmin. Semuanya dilakukan di Jawa, berjalan di mana saja, secara teori.
T-UP terlihat seperti ini:
Jendela utama: koneksi basis data.
Jika Anda mengklik Opsi, Anda dapat mengonfigurasi sesuatu.
Yang paling penting, Anda dapat memilih jenis objek yang akan dimigrasi.Tidak ada instruksi, bantuan, tip yang dapat ditemukan.
Itu membuat kesan utilitas buatan sendiri. Kadang-kadang dia terbang dengan eksekusi, tetapi pada dasarnya dia bekerja sesuai kebutuhan.
Alat kedua adalah Tibero Admin IDE. Itu dapat diunduh dari situs web TMaxSoft jika Anda mendaftar terlebih dahulu. Anda juga bisa mendapatkan lisensi demo di sana.
Tibero Admin terlihat seperti IDE lama yang khasSaya sudah terbiasa dengan alat Pengembang PL / SQL yang sangat baik dari Allround Automations. Di Tibero Admin, lupakan permintaan kontekstual, tidak ada yang akan muncul di layar Anda setelah mengklik "titik", itu tidak akan menambahkan nama tabel dan objek kepada Anda. Cukup ketik kode, Anda pemrogram. Bantuan, dokumentasi? Tidak. Ada dokumentasi tentang DBMS di situs web pabrikan, sangat menarik ... tanpa pencarian. Tidak ada dokumentasi yang ditemukan untuk IDE. Namun, tidak ada yang rumit. Ada masalah dengan otorisasi - ternyata pengguna harus diberikan hak DBA untuk masuk ke tbAdmin. Dan menarik dengan port
, 8630 adalah untuk SYS, untuk yang lain 8629 .
Bug IDE. Dari waktu ke waktu, ketika Anda mencari di suatu tempat,
indeks pesan di
luar batas terbang
keluar , pesan seperti
java.lang.Exception: komitmen berhasil sangat menakutkan. Hal ini diperlukan untuk mempertimbangkan berbagai jenis jendela SQL dan PSM: Pada yang pertama, Anda tidak mungkin untuk mengkompilasi kode program, di yang kedua, Anda tidak akan menjalankan permintaan. Setelah Pengembang PL / SQL - kemiripan yang menyedihkan dari tangan kiri ...
Mulai ke percobaan.
Migrasi Tabel
Kami memilih skema di T-UP, klik Migrasi, pertama pilih "tabel" di opsi dan proses transfer dimulai. Saya mengalami dua masalah.
TABLESPACES. Saya memutuskan untuk mentransfernya ke tabel, tetapi Tibero tampaknya telah mencoba untuk memesan ruang sebanyak mungkin untuk mereka seperti yang mereka habiskan di basis data sumber. Dan ini banyak, dan dia tidak bisa. Saya membuat ruang tabel secara manual, dan kemudian semuanya berjalan dengan baik.
Selain tabel dengan nilai tanggal DEFAULT ketik '31 .12.2019 '. Dalam pengaturan Oracle, kami telah mendaftarkan format ini, karena Tibero sangat membantu
alter session set nls_date_format='DD.MM.YYYY';
tetapi tidak ada tempat bagi T-UP untuk melakukannya. Kolega dari TMaxSoft menyarankan pengaturan variabel TB_NLS_DATE_FORMAT = "DD.MM.YYYY", tetapi itu tidak membantu saya secara pribadi. Mungkin saya melakukan sesuatu yang salah. Saya harus membuat tabel dengan parameter seperti itu secara manual, tidak banyak.
Hasil dari langkah pertama: memindahkan struktur tabel dari Oracle ke Tibero berfungsi dengan baik.
Kunci dan indeks.
Kami memilih kotak centang INDEX, CONSTRAINT di T-UP, dan meneruskan. Masalah muncul dengan PERIKSA karena situasi yang sama dengan tanggal. Secara umum, indeks, kunci utama, cek - telah dibuat. Tapi saya tidak dapat menemukan kunci asing di database yang baru dibuat. Dan migrasi konstanta berakhir pada log T-UP dengan pesan
"Migration Failed: java.lang.NullPointerException". Kebetulan? Saya kira tidak ...
Paket dan pemicu.
Dalam pemicu saya tidak ada yang rumit, mereka diciptakan dengan sempurna. Benar, saya tidak memeriksa cara kerjanya, ini akan menjadi cerita yang terpisah.
Mari kita bicara tentang prosedur dan fungsi yang mengimplementasikan bagian dari logika. Di sini, sayangnya, tidak semuanya berjalan dengan sempurna.
Sederhana: di
pasukan Tibero tidak ada kata
BARU . O: = Konstruksi BARU t_my_type () tidak akan dikompilasi. Di Oracle, itu benar, tidak wajib, tetapi saya selalu menulis untuk beberapa alasan. Saya harus menghapus.
Peran DBA memungkinkan SQL Window untuk mengakses semua tabel. Namun, ketika menyusun paket atau prosedur dalam skema dengan peran seperti itu, saat menggunakan tabel dan objek skema lain, Anda perlu memberikan hibah yang sesuai ke objek. Keajaiban peran DBA tidak membantu di sini.
Dari yang spesifik. Saya mendapat FORALL yang aneh di basis data saya, yang, bagaimanapun, berfungsi.
Tibero mengatakan
“pernyataan dml harus memiliki parameter bulk-in untuk semua tutup” . Dan saya mengerti jauh di lubuk hati, tetapi kode ini harus diulang dalam siklus reguler.
Situasi dengan tabel yang berisi objek lebih buruk.
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;
Kami memiliki kesalahan kompilasi, ketik mistmatch.
Orang-orang dari TMaxSoft mengusulkan versi kode ini:
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;
Bekerja mungkin berhasil. Tetapi tidak begitu nyaman, dan Anda harus mengulang kodenya.
Sisanya dikompilasi secara normal, kecuali untuk hal-hal tertentu seperti SDO_GEOM. Dan omong-omong, Tibero memiliki analog. Tangannya belum mencapai ruang kerjanya.
Jenis
Dalam salah satu proyek, kami menggunakan kekuatan OOP oleh Oracle hollow.
Pertanyaan paling menarik bagi Tibero adalah tentang ini.
Kami membuat jenis tertentu, yang merupakan dasar untuk satu set jenis lainnya.
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;
Dan sekarang kami mencoba untuk membuat ahli waris yang layak untuknya.
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;
Compiler akan menolak untuk mengesampingkan fungsi target. Namun, tidak ada pertanyaan tentang fungsi klon. Ternyata Tibero tidak suka OVERRIDING ketika metode memiliki parameter. Oke, hapus kata OVERRIDING. Tapi ini mengkhawatirkan, dan kami menulis skrip uji. Sejauh ini dengan tipe induknya.
declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target;
Tampaknya kita tidak meninggalkan pilihan untuk program ini, tidak peduli apa nilai yang diambil variabel i1, sesuatu akan muncul di output. Tapi ... tidak ada yang muncul!
Saya langsung ingat film yang bagusKeanehan ini tidak berakhir di sini. Membuat percobaan lebih buruk
declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target;
Bahkan fakta bahwa setelah semua manipulasi dengan metode objek, kita secara kaku mengatur nilai variabel, tidak mengubah apa pun - output kosong.
Kendalikan eksperimen, uji diri Anda sendiri untuk kegilaan:
declare o1 t_tar_object; i1 number ; begin o1 := t_tar_object; o1.id := 1;
"Besar" yang dihargai muncul di output. Menyeramkan, bukan? Menggunakan poke ilmiah, orang-orang dari TMaxSoft menemukan bahwa jika Anda menghapus nuansa "TIDAK FINAL" dari spesifikasi t_tar_object, maka objek akan berperilaku tepat. Tapi mengapa kita membutuhkan ... tanpa ahli waris.
Tidak ada gunanya membicarakan lebih lanjut tentang OOP di Tibero. Seperti, pada kenyataannya, OOP di Tibero. Setelah itu, pertanyaan lain muncul: dan kode prosedur dan fungsi yang dikompilasi - apakah itu berfungsi dengan benar? Saya belum tahu. Sejumlah besar kode telah berimigrasi dan dikompilasi. Untuk proyek yang tidak mengandung jenis latihan di atas, ini adalah keberhasilan yang pasti. Tetapi menguji eksekusi kode yang benar adalah tugas yang serius. Dan jujur saja, saya tidak berharap bertemu dengannya. Saya tidak akan siap untuk mengatakan apakah saya akan memiliki proyek pada DBMS ini. Tetapi jika itu terjadi, maka pengembangan akan dilakukan pada Oracle, menggunakan alat yang mudah dan normal, dan dengan migrasi reguler ke Tibero. Menulis kode dalam IDE tanpa petunjuk kontekstual dan dengan kesalahan periodik dari antarmuka itu sendiri adalah kesenangan di bawah rata-rata.
Kesimpulan
Apakah Tibero memiliki masa depan dalam kondisi saat ini? Tidak yakin Lagi pula, jika Anda melihat biaya lisensi tidak termasuk megascale, maka satu soket Standar berharga sekitar 800.000. Yang lebih murah daripada Oracle, tetapi tidak kadang-kadang. Dan seperti yang saya yakini dari pengalaman saya sendiri, sejauh ini bahkan tidak dekat Oracle.
Apakah masuk akal untuk menggunakan Tibero yang hampir gratis yang ditawarkan sekarang? Mungkin ya. Mereka mengatakan bahwa ketika membayar biaya dukungan teknis (99.000 rubel per tahun untuk soket), diizinkan untuk menggunakan pangkalan ini dalam proyek komersial. Jika Anda memiliki tim oracleis yang tersedia, dan Anda perlu membuat dan menempatkan sesuatu yang tidak terlalu rumit di server Anda, tetapi lebih murah dan lebih cepat - opsi yang menarik. Anda masih dapat memainkan kartu sanksi, memberi tahu pelanggan yang bermasalah bahwa Korea bukan Amerika Serikat.
Haruskah saya menerjemahkan proyek yang ada dari Oracle ke Tibero? Tidak mungkin. Tidak ada alasan untuk mencari petualangan seperti itu. Lebih mudah untuk memberikan dukungan teknis Oracle dan tidak membayar apa pun kepada siapa pun.
Dan jika Anda perlu membuat contoh baru dari proyek lama yang berjalan di Oracle? Dan sebagai hasilnya, beli lisensi baru? Pikirkan di sini. Ada kemungkinan bahwa pangkalan Anda akan bermigrasi dan bekerja secara kualitatif. Tetapi segera pikirkan tentang mendukung dua area dalam proyek, atau menerjemahkan semuanya ke Tibero. Kami mempertimbangkan biaya tenaga kerja, risiko, dan manfaat dari lisensi yang lebih murah. Bandingkan, putuskan.
Mungkin dalam versi Tibero berikutnya semuanya akan berbeda. Itu hanya perlu untuk menyelesaikan jenis, membuat IDE normal, mungkin mengubah kebijakan harga. Dan jika DBMS sama dengan mobil, maka setelah 5 tahun orang Korea dapat menduduki pangsa pasar yang signifikan dan menggantikan hegemon. Kami akan melihat.
PS
Nilai tambah yang serius ketika memilih DBMS untuk proyek baru dapat berupa dukungan teknis TMaxSoft. Saya bahkan tidak membeli lisensi untuk satu dolar, dan orang-orang itu menjawab saya dengan sangat cepat, jelas tertarik. Mereka membantu dengan kedua pertanyaan bodoh dan yang dijelaskan di sini. Umpan baliknya sangat bagus.