IBM pureXML, database XML berpemilik yang dibangun di atas mekanisme relasional (dirancang untuk permainan kata-kata) yang menawarkan bahasa kueri relasional ( SQL / XML ) dan tidak terstruktur ( XQuery ), dan MarkLogic, database yang dibangun dari gores berdasarkan paradigma database baru (sebut saja NoSQL jika Anda mau) yang memahami data tidak terstruktur dan menawarkan bahasa kueri tidak terstruktur ( XQuery ).
Informasi penting lainnya adalah tren baru di antara penyedia basis data NoSQL untuk mengimplementasikan SQL (atau antarmuka seperti SQL). Contohnya adalah promosi terbaru Cassandra dengan CQL atau bahkan antarmuka SQL yang lebih matang berdasarkan Hadoop.
Saat dua dunia bertabrakan
NoSQL tentang Tanpa SQL . Bagi saya, ini berarti mengalihkan penekanan ke alternatif basis data non-relasional, yang bahkan dapat menjelajahi antarmuka yang berbeda ke basis data (dan tidak peduli dengan kebenaran politik). Ini adalah hal yang baik! Mengakui kelemahan SQL untuk bisnis secara membabi buta? Yah, bahkan jika SQL adalah pilihan yang tepat untuk produk Anda, Anda masih harus memikirkan konsekuensinya dan memastikan bahwa semuanya selaras antara dua dunia. Dengan kata lain, itu berarti menghapus bagian "buta" dan mengurangi "lumpuh" ke tingkat minimum yang dapat diterima untuk pengembang Anda.
Model Data
Dalam relasional Anda memiliki:
RowSet -> SQL -> RowSet
RowSet adalah sesuatu seperti itu:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Saya akan memberi tahu Anda tentang model data XPath:
XDM -> XPath/XQuery -> XDM
Dan XDM adalah seperti itu:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Keduanya disederhanakan, tetapi memiliki tujuan) .
Ciri khas model data untuk dokumen adalah bahwa pohonnya tidak rata:
{
"namespace": "person-2.0",
"comments": "This guy asked me for a dinosaur sticker. What a nutter!",
"person": {
"handle": "dscape",
"comments": "Please do not send unsolicited mail."
}
}
Jadi, ada banyak interpretasi tentang apa artinya ini:
SELECT comments from PERSON where handle = "dscape"
Elemen "komentar" mana yang dirujuk oleh permintaan? Jika Anda melihat SQL / XML, kueri Anda akan terlihat seperti ini:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Ini mengarah pada kesimpulan yang jelas:pohon membutuhkan cara untuk bernavigasi. Dalam XML itu XPath, di JSON mungkin JSONSelect, mungkin sesuatu yang lain. Tetapi Anda masih memerlukan metode navigasi standar sejak awal.
Yang membuat tugas ini lebih menarik adalah kontrol versi dan pengembangan sirkuit. Terlepas dari kenyataan bahwa ini telah diabaikan selama berabad-abad di dunia relasional (dengan konsekuensi serius bagi bisnis karena downtime di saat-saat lucu perubahan tabel ini). , ini memang tidak boleh diabaikan untuk dokumen. Pikirkan tentang Microsoft Word – berapa banyak versi berbeda dari dokumen yang mereka dukung? Word 2003, 2005, dll.
Tidak ada skema, fleksibilitas, tidak terstruktur:pilih kata Anda, tetapi semuanya tunduk pada evolusi format data yang cepat. Dalam kueri ini, kami berasumsi bahwa deskriptor adalah anak manusia dan komentar bahwa saya idiot adalah keturunan langsung dari pohon. Ini pasti akan berubah. Dan SQL tidak mendukung pembuatan versi dokumen, jadi Anda harus memperluasnya agar berfungsi.
Bahasa kueri sebenarnya untuk data tidak terstruktur harus mempertimbangkan versinya. Di XQuery kami dapat mengekspresikan kueri ini sebagai sesuatu seperti itu:
declare namespace p = "person-2.0" ;
for $person in collection('person')
let $comments-on-person := $person/p:comments
where $person/p:handle = "dscape"
return $comments-on-person
Frankenqueries, misalnya
Seseorang pernah menyebut saya (berbicara tentang SQL / XML) sebagai Frankenqueries ini. Istilah itu melekat di kepala saya sejauh ini. Mari kita lihat lebih jauh analogi ini dan mencari tempat di mana bagian organik dan baut menyatu.
Mari kita tunjukkan dua daftar belanja, satu untuk Joe dan satu untuk Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Sekarang dengan ekstensi SQL / JSON "imajiner" saya, saya melakukan:
SELECT apples
FROM LISTS
Apa itu kembali? Ingat, RowSet masuk, RowSet keluar?
2, 5
---
6
Jadi, bahkan jika Anda secara eksplisit meminta daftar nomor apel, Anda mendapatkan dua set baris, bukan tiga, dan salah satu set baris akan memiliki daftar nomor. Jika Anda memilih untuk mengembalikan tiga hal, Anda akan mendapatkan dua set RowSet dan tiga set RowSet. Saya bukan ahli matematika, tapi kedengarannya tidak bagus.
Sekali lagi, tidak masalah jika Anda menggunakan sesuatu yang mungkin menangani informasi tidak terstruktur. Anda tidak memiliki masalah ini di javascript dan tentu saja, tidak akan ada di XQuery. Baik dalam javascript dan XQuery semuanya organik.
Kesimpulan:bahasa yang menakjubkan untuk data tidak terstruktur, unicorn, dan debu peri!
Meskipun XQuery adalah bahasa yang sangat baik untuk informasi tidak terstruktur, sudut pandang saya di sini tidak melindungi penggunaannya. Poin yang coba saya tekankan adalah perlunya bahasa yang nyata untuk data tidak terstruktur, tidak peduli bagaimana Anda (baca:developer) memilihnya.
Tapi saya meminta Anda (para pengembang) untuk tidak mengambil kembali "SQL lumpuh". Dia pergi, dan Anda memiliki kencan baru yang disebut NoSQL. Beri saja waktu dan itu akan tumbuh pada Anda. Menulis kode JavaScript yang berfungsi di database juga sangat menyenangkan:jangan biarkan mereka mengambilnya dari Anda.
SQL untuk data tidak terstruktur akan gagal. Maka PL-SQL untuk data tidak terstruktur akan gagal. Jadi jika vendor bersikeras pada apa yang Anda butuhkan, jangan terima apa pun selain bahasa pemrograman lengkap:Anda dapat menulis aplikasi lengkap Anda dalam javascript dan menyimpannya di CouchApp, atau Anda dapat menulis aplikasi lengkap Anda di XQuery dan menyimpannya di MarkLogic . Dan memang seharusnya begitu!
Berikut adalah daftar periksa apa yang harus dicari dalam bahasa kueri untuk informasi tidak terstruktur:
- Bahasa navigasi
- Model Data
- Ekspresi normal
- Lambda
- Fungsi tingkat tinggi
- Aroma fungsional
- Pemrosesan baris yang baik
- Modul sehingga Anda dapat membuat perpustakaan sendiri
- Server aplikasi mengetahui:memiliki fungsi yang melayani REST
Anda mungkin mengabaikan saran ini, tetapi pada akhirnya, Anda mungkin merasa frustrasi dengan pengembang Silverlight. Dan kami, orang-orang yang suka berinovasi dalam basis data, akan kecewa karena para pengembang memutuskan untuk kembali!
