Dengan sebagian besar, jika tidak semua 2018 di belakang kami (tergantung pada saat Anda membaca posting ini), tidak ada keraguan bahwa itu adalah tahun yang fantastis untuk database SQL open-source.
PostgreSQL 11 dan MySQL 8 keduanya dirilis, memberikan banyak hal bagi kedua komunitas untuk 'dibicarakan '. Sejujurnya, kedua vendor telah memperkenalkan banyak perubahan dan penambahan signifikan dalam rilis masing-masing dan pantas mendapatkan pujian dan penghargaan.
Saya biasanya memposting tamu tentang yang pertama di sini di blog Somenines (Terima kasih banyak untuk organisasi yang hebat!) tetapi saya juga tertarik pada yang terakhir. Dengan banyak posting blog di situs web saya sendiri (tautan di bagian bio saya), sebagian besar menargetkan MySQL versi 5.7, itu (MySQL) selalu ada di periferal saya.
Jadi apa yang dimiliki MySQL 8 yang tidak dimiliki versi 5.7? Apa saja perbaikannya? Ada banyak. Faktanya, terlalu banyak untuk dibahas hanya dalam satu posting blog.
Saya baru-baru ini meningkatkan ke versi 8 di lingkungan pembelajaran/pengembangan Linux saya saat ini, jadi saya berpikir untuk mencoba menunjukkan beberapa di antaranya.
Saya tidak dapat menjamin Anda diskusi mendalam tentang 'favorit your Anda ' fitur baru). Di sisi lain, saya akan mengunjungi orang-orang yang telah menarik perhatian saya baik melalui minat pribadi atau melalui banyak posting blog hebat yang diterbitkan sepanjang tahun di versi 8.
MySQL menjadi lebih baik dan lebih baik...Peningkatan hebat di versi 8!
Peran
Dengan Peran, DBA dapat mengurangi redundansi, di mana banyak pengguna akan berbagi hak istimewa atau kumpulan hak istimewa yang sama.
Peran adalah bagian dari standar SQL.
Setelah membuat peran tertentu dengan hak istimewa yang diinginkan/diperlukan, Anda kemudian dapat menetapkan peran tertentu kepada pengguna melalui perintah GRANT atau, 'menghapus ' dengan REVOKE.
Peran datang dengan banyak manfaat dan untuk membuat hidup sedikit lebih mudah, ada beberapa tabel untuk membantu Anda melacaknya:
-
mysql.role_edges - Di sini Anda menemukan peran tersebut dan pengguna yang ditetapkan.
mysql> DESC mysql.role_edges; +-------------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+---------------+------+-----+---------+-------+ | FROM_HOST | char(60) | NO | PRI | | | | FROM_USER | char(32) | NO | PRI | | | | TO_HOST | char(60) | NO | PRI | | | | TO_USER | char(32) | NO | PRI | | | | WITH_ADMIN_OPTION | enum('N','Y') | NO | | N | | +-------------------+---------------+------+-----+---------+-------+ 5 rows in set (0.01 sec) -
mysql.default_roles - Menyimpan semua peran default dan pengguna yang ditetapkan.
mysql> DESC mysql.default_roles; +-------------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+----------+------+-----+---------+-------+ | HOST | char(60) | NO | PRI | | | | USER | char(32) | NO | PRI | | | | DEFAULT_ROLE_HOST | char(60) | NO | PRI | % | | | DEFAULT_ROLE_USER | char(32) | NO | PRI | | | +-------------------+----------+------+-----+---------+-------+ 4 rows in set (0.00 sec)
Kombinasi kedua tabel (bukan dalam pengertian SQL JOIN) pada dasarnya menyediakan 'lokasi terpusat ' di mana Anda dapat:mengetahui, memantau, dan menilai semua hubungan dan penetapan hak istimewa peran pengguna yang diterapkan.
Kemungkinan contoh skenario penggunaan peran yang paling sederhana adalah:
Anda memiliki beberapa pengguna yang membutuhkan 'akses hanya baca ' pada tabel tertentu, oleh karena itu, membutuhkan setidaknya hak istimewa SELECT. Alih-alih memberikannya (PILIH) satu per satu kepada setiap pengguna, Anda dapat membuat (membuat) peran yang memiliki hak istimewa itu, lalu menetapkan peran itu kepada pengguna tersebut.
Tapi, peran datang dengan sedikit 'menangkap '. Setelah dibuat dan ditetapkan ke pengguna, pengguna penerima harus memiliki set peran default aktif, selama otentikasi saat login.
Sementara pada subjek peran dan pengguna, saya merasa penting untuk menyebutkan perubahan yang diterapkan di MySQL 8 tentang komponen validasi_kata sandi, yang merupakan varian dari plugin validasi_kata sandi yang digunakan di versi 5.7 .
Komponen ini menyediakan berbagai 'kategori . yang berbeda ' dari pemeriksaan kata sandi:rendah, sedang (default), dan kuat. Kunjungi dokumentasi komponen validation_password untuk ikhtisar lengkap tentang spesifikasi validasi setiap level.
Penggabungan NoSQL dengan SQL - The Document Store
Fitur ini adalah salah satu yang masih saya pelajari, meskipun minat sekilas pada MongoDB di awal 2016. Sampai saat ini, minat, studi, dan pembelajaran saya hanya terfokus pada 'SQL'. Namun, saya menyadari (melalui banyak membaca di web) bahwa banyak yang tertarik dengan jenis penataan (berorientasi dokumen) yang terkait dengan 'SQL relasional' yang sekarang tersedia di penyimpanan dokumen MySQL 8.
Di bawah ini adalah banyak manfaat yang tersedia saat menggunakan penyimpanan dokumen. Pastikan dan sebutkan favorit Anda yang mungkin saya lewatkan di bagian komentar:
- Tipe data JSON telah didukung sejak MySQL versi 5.7.8 namun, versi 8 memperkenalkan peningkatan signifikan untuk bekerja dengan JSON. Fungsi khusus JSON baru bersama dengan 'shorthand ' operator yang dapat digunakan sebagai pengganti beberapa panggilan fungsi - dengan hasil/output yang sama.
- Mungkin salah satu manfaat terpenting adalah Anda tidak perlu lagi menerapkan dan bekerja dengan beberapa solusi database karena NoSQL, SQL, atau kombinasi keduanya didukung di penyimpanan dokumen.
- "DevAPI", memberikan kemampuan alur kerja yang mulus dalam konteks data NoSQL (koleksi dan dokumen). (Kunjungi dokumentasi panduan pengguna DevAPI resmi untuk informasi lebih lanjut).
- Sesi baris perintah yang andal menggunakan Python, SQL, atau Javascript sebagai bahasa 'shell'.
- Sesuai dengan ACID.
- Jelajahi dan temukan data Anda dengan cepat tanpa mendefinisikan skema seperti yang Anda lakukan dalam model relasional.
Ekspresi Tabel Umum (klausa CTE atau WITH)
Apa lagi yang bisa Anda katakan tentang CTE? Hal-hal ini adalah pengubah permainan! Sebagai permulaan, apa sebenarnya ekspresi tabel yang umum?
Dari Wikipedia:
"Ekspresi tabel umum, atau CTE, (dalam SQL) adalah kumpulan hasil bernama sementara, yang diturunkan dari kueri sederhana dan didefinisikan dalam lingkup eksekusi pernyataan SELECT, INSERT, UPDATE, atau DELETE."
Saya akan memberikan contoh sederhana, mendemonstrasikan CTE. Namun, kekuatan penuh mereka tidak dimanfaatkan di bagian ini, karena ada banyak contoh kasus penggunaan yang lebih kompleks daripada ini.
Saya memiliki tabel nama sederhana dengan deskripsi dan data ini:
mysql> DESC name;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| f_name | varchar(20) | YES | | NULL | |
| l_name | varchar(20) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Mari kita cari tahu berapa banyak nama belakang yang dimulai dengan 'Z':
mysql> SELECT *
-> FROM name
-> WHERE l_name LIKE 'Z%';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Cukup mudah.
Namun, dengan menggunakan klausa WITH, Anda dapat 'mengakses ' kumpulan hasil kueri yang sama ini (yang dapat dianggap sebagai tabel turunan) dan merujuknya nanti dalam pernyataan yang sama - atau 'lingkup ':
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT * FROM last_Z;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Saya pada dasarnya menetapkan nama untuk kueri, membungkusnya dalam tanda kurung. Kemudian pilih saja data yang saya inginkan dari yang sekarang menjadi last_Z CTE.
CTE last_Z memberikan rangkaian hasil yang lengkap, sehingga Anda dapat memfilternya lebih jauh dalam pernyataan yang sama:
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT f_name, l_name FROM last_Z WHERE l_name LIKE '%a';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Beberapa fitur yang lebih canggih adalah 'rantai ' beberapa CTE bersama-sama dan merujuk ke CTE lain dalam CTE.
Berikut adalah contoh untuk memberi Anda ide (walaupun tidak terlalu berguna):
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%'),
best_friend AS (
SELECT f_name, l_name
FROM last_Z
WHERE l_name LIKE '%a')
SELECT * from best_friend;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Dalam kueri di atas, Anda dapat melihat di mana saya memisahkan CTE last_Z dari CTE best_friend dengan koma lalu membungkus kueri itu dalam tanda kurung setelah kata kunci AS.
Perhatikan, saya kemudian dapat merujuk (dan menggunakan) CTE last_Z untuk mendefinisikan CTE best_friend.
Berikut adalah beberapa alasan mengapa CTE merupakan peningkatan yang signifikan di versi 8:
- Vendor SQL lain telah mendukung CTE (banyak sejak versi sebelumnya dalam ekosistem masing-masing) dan sekarang MySQL 8, telah menutup celah di area ini.
- Inklusi SQL standar.
- Dalam beberapa kasus (jika sesuai), CTE adalah opsi yang lebih baik daripada Tabel Sementara, Tampilan, Tabel Turunan (atau Tampilan Sebaris), dan beberapa subkueri.
- CTE dapat memberikan 'on-the-fly ' kumpulan hasil perhitungan yang dapat Anda kueri.
- CTE dapat mereferensikan dirinya sendiri - dikenal sebagai CTE rekursif (tidak ditunjukkan di sini).
- CTE dapat memberi nama dan menggunakan CTE lain
Fungsi Jendela
Kueri analitik sekarang dimungkinkan di MySQL 8. Karena fungsi Window tidak cocok untuk saya, saya fokus pada studi yang lebih mendalam dan pemahaman yang lebih baik tentang mereka, secara keseluruhan, bergerak maju. Contoh-contoh berikut ini sebagian besar bersifat dasar menurut pemahaman saya. Saran, saran, dan praktik terbaik diterima dari pembaca.
Saya memiliki VIEW ini yang menyediakan kumpulan hasil data pipa fiktif (sesuatu yang agak saya pahami):
mysql> SELECT * FROM pipe_vw;
+---------+-------------+-----------+-------+-------------+------------+----------------+
| pipe_id | pipe_name | joint_num | heat | pipe_length | has_degree | wall_thickness |
+---------+-------------+-----------+-------+-------------+------------+----------------+
| 181 | Joint-278 | 39393A | 9111 | 17.40 | 1 | 0.393 |
| 182 | Joint-8819 | 19393Y | 9011 | 16.60 | 0 | 0.427 |
| 183 | Joint-9844 | 39393V | 8171 | 10.40 | 0 | 0.393 |
| 184 | Joint-2528 | 34493U | 9100 | 11.50 | 1 | 0.427 |
| 185 | Joint-889 | 18393z | 9159 | 13.00 | 0 | 0.893 |
| 186 | Joint-98434 | 19293Q | 8174 | 9.13 | 0 | 0.893 |
| 187 | Joint-78344 | 17QTT | 179 | 44.40 | 1 | 0.893 |
| 188 | Joint-171C | 34493U | 17122 | 9.45 | 1 | 0.893 |
| 189 | Joint-68444 | 17297Q | 6114 | 11.34 | 0 | 0.893 |
| 190 | Joint-4841R | 19395Q | 5144 | 25.55 | 0 | 0.115 |
| 191 | Joint-1224C | 34493U | 8575B | 15.22 | 1 | 0.893 |
| 192 | Joint-2138 | 34493C | 91 | 13.55 | 1 | 0.893 |
| 193 | Joint-122B | 34493U | 9100B | 7.78 | 1 | 0.893 |
+---------+-------------+-----------+-------+-------------+------------+----------------+
13 rows in set (0.00 sec)Bayangkan, saya membutuhkan catatan aset pipa yang disajikan dalam semacam peringkat baris tergantung pada panjang masing-masing pipa. (Misalnya, Panjang terpanjang adalah 'berlabel' posisi nomor 1, panjang terpanjang kedua adalah 'berlabel' posisi 2, dll...)
Berdasarkan deskripsi Fungsi Jendela RANK() dalam dokumentasi:
"Mengembalikan peringkat baris saat ini dalam partisinya, dengan celah. Peer dianggap mengikat dan menerima peringkat yang sama. Fungsi ini tidak menetapkan peringkat berurutan ke grup rekan jika grup berukuran lebih besar dari satu ada; hasilnya adalah nomor peringkat yang tidak bersebelahan ."
Tampaknya sangat cocok untuk persyaratan ini.
mysql> SELECT pipe_name, pipe_length,
-> RANK() OVER(ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+---------------+
| pipe_name | pipe_length | long_to_short |
+-------------+-------------+---------------+
| Joint-78344 | 44.40 | 1 |
| Joint-4841R | 25.55 | 2 |
| Joint-278 | 17.40 | 3 |
| Joint-8819 | 16.60 | 4 |
| Joint-1224C | 15.22 | 5 |
| Joint-2138 | 13.55 | 6 |
| Joint-889 | 13.00 | 7 |
| Joint-2528 | 11.50 | 8 |
| Joint-68444 | 11.34 | 9 |
| Joint-9844 | 10.40 | 10 |
| Joint-171C | 9.45 | 11 |
| Joint-98434 | 9.13 | 12 |
| Joint-122B | 7.78 | 13 |
+-------------+-------------+---------------+
13 rows in set (0.01 sec)Dalam skenario berikutnya, saya ingin membangun lebih jauh dari contoh sebelumnya dengan memberi peringkat catatan dengan panjang terpanjang hingga terpendek, tetapi, per setiap grup individu dari nilai wall_thickness yang berbeda.
Mungkin pertanyaan dan hasil di bawah ini akan menjelaskan dengan lebih baik di mana prosa saya mungkin belum:
mysql> SELECT pipe_name, pipe_length, wall_thickness,
-> RANK() OVER(PARTITION BY wall_thickness ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+----------------+---------------+
| pipe_name | pipe_length | wall_thickness | long_to_short |
+-------------+-------------+----------------+---------------+
| Joint-4841R | 25.55 | 0.115 | 1 |
| Joint-278 | 17.40 | 0.393 | 1 |
| Joint-9844 | 10.40 | 0.393 | 2 |
| Joint-8819 | 16.60 | 0.427 | 1 |
| Joint-2528 | 11.50 | 0.427 | 2 |
| Joint-78344 | 44.40 | 0.893 | 1 |
| Joint-1224C | 15.22 | 0.893 | 2 |
| Joint-2138 | 13.55 | 0.893 | 3 |
| Joint-889 | 13.00 | 0.893 | 4 |
| Joint-68444 | 11.34 | 0.893 | 5 |
| Joint-171C | 9.45 | 0.893 | 6 |
| Joint-98434 | 9.13 | 0.893 | 7 |
| Joint-122B | 7.78 | 0.893 | 8 |
+-------------+-------------+----------------+---------------+
13 rows in set (0.00 sec)Kueri ini menggunakan klausa PARTITION BY pada kolom wall_thickness karena kami menginginkan peringkat (yang disediakan ORDER BY pipe_length DESC), namun, kami membutuhkannya dalam konteks grup wall_thickness individu.
Setiap peringkat kolom long_to_short direset kembali ke 1 saat Anda menemukan (atau mengubah) ke nilai kolom wall_thickness yang berbeda.
Mari berkonsentrasi pada hasil satu grup.
Menargetkan catatan dengan nilai wall_thickness 0.893, baris dengan pipe_length 44.40 memiliki 'peringkat' long_to_short yang sesuai dari 1 (ini yang terpanjang), sedangkan baris dengan pipe_length 7.78 memiliki 'peringkat' long_to_short yang sesuai dari 8 (terpendek) semua di dalamnya kelompok tertentu (0,893) dari nilai ketebalan dinding.
Fungsi jendela cukup kuat dan seluruh cakupan dan luasnya tidak mungkin tercakup dalam satu bagian saja. Pastikan dan kunjungi Fungsi Jendela yang didukung dalam dokumentasi MySQL 8 untuk informasi lebih lanjut tentang yang saat ini tersedia.
Peningkatan Dukungan dan Kemampuan Spasial
Ini adalah serangkaian fitur luar biasa yang disertakan dalam MySQL 8. Dukungan versi sebelumnya, atau kekurangannya, tidak dapat dibandingkan dengan implementasi vendor lain (pikirkan PostGIS untuk PostgreSQL).
Selama lebih dari 10 tahun terakhir, saya telah bekerja di lapangan sebagai Surveyor Pipa, mengumpulkan GPS dan data aset, jadi kelompok perubahan ini pasti menarik perhatian saya.
Keahlian data spasial adalah subjek yang komprehensif dalam dirinya sendiri dan yakinlah, saya jauh dari ahli dalam hal itu. Namun, saya berharap dapat merangkum perubahan signifikan antara versi 5.7 dan 8 dan menyampaikannya secara jelas dan ringkas.
Mari berkenalan dengan 2 istilah (dan konsep) kunci untuk tujuan bagian ini.
-
Sistem Referensi Spasial atau SRS - Berikut adalah sebagian definisi dari Wikipedia:
Sistem referensi spasial (SRS) atau sistem referensi koordinat (CRS) adalah sistem lokal, regional atau global berbasis koordinat yang digunakan untuk menemukan entitas geografis. Sistem referensi spasial mendefinisikan proyeksi peta tertentu, serta transformasi antara referensi spasial yang berbeda. sistem."
-
Pengidentifikasi Sistem Referensi Spasial atau SRID - Wikipedia juga mendefinisikan SRID sebagai berikut:
"Pengidentifikasi Sistem Referensi Spasial (SRID) adalah nilai unik yang digunakan untuk mengidentifikasi secara jelas definisi sistem koordinat spasial yang diproyeksikan, tidak diproyeksikan, dan lokal. Sistem koordinat ini membentuk inti dari semua aplikasi GIS."
MySQL mendukung banyak tipe data spasial. Salah satu yang lebih umum adalah POINT. Jika Anda menggunakan GPS untuk menavigasi ke restoran favorit Anda, maka lokasi tersebut adalah TITIK di peta.
MySQL 5.7 menangani hampir semua 'objek spasial ' memiliki SRID 0, yang signifikan untuk komputasi. Perhitungan tersebut dihitung dalam sistem koordinat jenis Cartesian. Namun, kita semua tahu bahwa bola dunia kita adalah bola dan jauh dari datar. Oleh karena itu, dalam versi 8, Anda memiliki kemampuan untuk menganggapnya sebagai datar atau bulat dalam komputasi.
Kembali ke dua istilah tersebut, yang telah kita definisikan sebelumnya.
Meskipun 0 adalah SRID default di MySQL versi 8, banyak (sekitar 5.000+) SRID lain yang didukung.
Tapi mengapa itu penting?
Penjelasan fantastis ini melalui posting blog, Sistem Referensi Spasial di MySQL 8.0, merangkumnya dengan baik:
"Secara default, jika kita tidak menentukan SRID, MySQL akan membuat geometri di SRID 0. SRID 0 adalah gagasan MySQL tentang bidang Catesian abstrak, tanpa unit, tak terbatas. Sementara semua SRS lain merujuk ke beberapa permukaan dan mendefinisikan unit untuk sumbu, SRID 0 tidak."
Pada dasarnya, saat melakukan perhitungan dengan SRID selain SRID 0 , maka bentuk Bumi kita ikut bermain, dipertimbangkan, dan memengaruhi perhitungan tersebut. Ini sangat penting untuk setiap perhitungan yang berarti/akurat. Untuk ikhtisar mendalam dan ekstrapolasi yang lebih baik, lihat posting blog ini yang mencakup geografi di MySQL 8.
Saya juga sangat merekomendasikan posting blog Tim Server MySQL, Sistem Referensi Spasial Geografis di MySQL 8.0, untuk kejelasan tentang SRS. Pastikan dan bacalah!
Terakhir, untuk masalah peningkatan data spasial dari versi 5.7 ke 8, kunjungi beberapa perubahan yang tidak kompatibel yang tercantum di sini untuk informasi lebih lanjut.
Pengamatan Penting Lainnya
Di bawah ini adalah peningkatan rilis lainnya yang harus saya akui, meskipun tidak dibahas secara mendalam dalam posting blog ini:
- utf8mb4 sekarang menjadi set karakter default (sebelumnya latin1) - Dukungan yang lebih baik untuk mereka yang harus memiliki emoji selain beberapa bahasa...
- Kamus Data Transaksional - Metadata MySQL sekarang disimpan di tabel InnoDB.
- Indeks Tak Terlihat - Mengatur visibilitas indeks untuk pengoptimal, yang pada akhirnya menentukan apakah menambahkan atau menghapusnya (indeks), adalah hal yang baik atau buruk. Menambahkan indeks ke tabel besar yang ada bisa jadi 'mahal ' dalam hal penguncian dan sumber daya.
- Indeks Menurun - Performa lebih baik pada nilai terindeks yang disimpan dalam urutan menurun.
- Instant Add Column - Untuk perubahan skema, tentukan ALGORITHM=INSTANT dalam pernyataan ALTER TABLE dan (jika memungkinkan untuk operasi) hindari penguncian metadata. (Untuk informasi lebih lanjut, lihat posting hebat ini oleh Tim Server MySQL, dan bagian ALTER TABLE dari dokumen resmi.)
Bagian Bonus:Sesuatu yang Saya Ingin Lihat...
Sumber daya terkait ClusterControl untuk MySQL Menjadi seri blog DBA MySQL - Operasi umum - Perubahan Topologi Replikasi Menjadi seri blog DBA MySQL - Peningkatan basis dataKendala pemeriksaan belum masuk ke produk MySQL.
Seperti versi MySQL sebelumnya, periksa sintaks batasan diperbolehkan dalam perintah CREATE TABLE Anda tetapi diabaikan. Sepengetahuan saya, sebagian besar vendor SQL lainnya mendukung batasan pemeriksaan. Ayo bergabung dengan pesta MySQL!
MySQL telah 'meningkatkan . secara signifikan ' penawarannya dalam versi 8. Mendukung kemampuan spasial yang kuat, pilihan peran manajemen pengguna yang nyaman, solusi data SQL/NoSQL 'hibrida', dan fungsi analitik di antara banyak peningkatan tambahan, benar-benar luar biasa.
Menurut pendapat saya, dengan versi 8, MySQL terus memberikan opsi yang solid dalam ekosistem SQL open-source kompetitif yang terus berkembang, penuh dengan solusi yang relevan dan kaya fitur.
Terima kasih telah membaca.
