Sebagai programmer kita harus tahu pada posisi mana kita sekarang sehingga kita bisa merencanakan arah pengembangan skill yang kita miliki. Berikut ini matriks sederhana untuk membantu kita menentukan tingkat skill programming kita, sekaligus membantu menentukan skill apa saja yang diperlukan untuk naik level… cheers
PostgreSQL | Setiap row di PostgreSQL memiliki dua ID transaksi: creation transaction ID yang menunjukkan ID transaksi yang membuat row tersebut, serta expiration transaction ID yang menunjukkan transaksi yang membuat row tersebut kedaluwarsa. Ketika UPDATE dilakukan, PostgreSQL menciptakan row baru dan meng-expire row lama. Ini row yang sama — hanya saja berbeda versi. PostgreSQL menciptakan row versi baru hasil perubahannya tapi juga mempertahankan row versi lama yang sudah kedaluwarsa.
Jelas kan sekarang….. kenapa namanya Multi-Versioning…. Pada sistem database yang menggunakan row-level locking tidak mempertahankan versi lama dari data yang diubah, sehingga kebutuhan untuk mengkunci data muncul untuk menjaga konsistensi data. Setelah sekarang Anda tahu bagaimana PostgreSQL menciptakan versi data, Anda mungkin bertanya-tanya bagaimana PostgreSQL bisa tahu versi yang mana untuk ditampilkan….
Setiap programmer yang pernah membuat aplikasi multi-user pasti pernah dibuat frustrasi gara-gara lock bisa menyebabkan pengguna menunggu atau bahkan sampai deadlock dan aplikasi hang. walaupun database yang digunakan sudah menggunakan table-level, page-level, column-level, atau row-level locking, masalah yang sama tetap muncul: SELECT oleh satu user nge-block UPDATE oleh user lain sampai transaksi user pertama selesai, dan juga sebaliknya UPDATE satu user nge-block SELECT oleh user lainnya sampai transaksi user pertama selesai. eSQL
Namun bagi Anda yang sudah menggunakan PostgreSQL pasti tahu bahwa problem seperti di atas tidak akan terjadi karena di PostgreSQL ada fitur canggih yang disebut Multi-Versioning Concurrency Control (MVCC) sehingga SELECT tidak pernah nge-block UPDATE, dan UPDATE tidak pernah nge-block SELECT.
Analisa dan Design | Kebanyakan kita programmer – terutama para pemula – ketika diminta membuat suatu program tertentu misalnya program inventory pasti akan langsung duduk di depan komputer *dan* dijamin pasti kebingungan musti ngapain dulu :)) Solusinya adalah….. Jangan langsung duduk di depan komputer untuk langsung coding… tapi mulai dengan mendefinisikan 5W +1H, dari aplikasi yang sedang kita buat. Kedengarannya seperti sedang membuat skripsi, namun yakinlah langkah ini salah satu tujuannya adalah agar proyek yang sedang kita kerjakan tidak sampai salah arah… Penjabaran ringkas masing-masing poin seperti di bawah ini….
Terakhir baru,
Setelah semua pertanyaan di atas terjawab… barulah mulai coding…
Happy analysis, design, and development
Membuat report adalah salah satu pekerjaan yang cukup rumit, lebih lagi jika harus membuat report crosstab dengan jumlah kolom yang dinamis dijamin pusing tujuh keliling. Laporan crosstab ini adalah laporan yang mengolah data mentah berupa baris-baris menjadi kolom-kolom.
Mencoba menjawab sejumlah pertanyaan tentang crosstab dinamis yang muncul di Facebook grup PHP Indonesia dan MySQL Indonesia, akhirnya saya penasaran juga….
Misalkan kita punya data transaksi seperti tabel di bawah ini:
+-------+------------+-------+ | kode | tanggal | nilai | +-------+------------+-------+ | CN235 | 2012-01-02 | 100 | | CN235 | 2012-01-11 | 140 | | CN235 | 2012-01-11 | 150 | | CN235 | 2012-01-15 | 160 | | CN235 | 2012-01-17 | 180 | | CN235 | 2012-01-17 | 170 | | CN236 | 2012-01-02 | 800 | | CN236 | 2012-01-11 | 200 | | CN236 | 2012-01-11 | 400 | | CN236 | 2012-01-15 | 120 | | CN236 | 2012-01-17 | 400 | | N2130 | 2012-01-02 | 120 | | N2130 | 2012-01-15 | 200 | | N2130 | 2012-01-17 | 600 | +-------+------------+-------+
Namun kita perlu membuat laporan seperti ini
+-------+------------+------------+------------+------------+-------+ | kode | 2012-01-02 | 2012-01-11 | 2012-01-15 | 2012-01-17 | total | +-------+------------+------------+------------+------------+-------+ | CN235 | 100 | 290 | 160 | 350 | 900 | | CN236 | 800 | 600 | 120 | 400 | 1920 | | N2130 | 120 | 0 | 200 | 600 | 920 | +-------+------------+------------+------------+------------+-------+
Kolom 2012-01-02 sampai 2012-01-17 sifatnya dinamis, artinya kolom tanggal bisa jadi tidak hanya 4 kolom, bisa lebih banyak, dan bisa juga lebih sedikit, tergantung dari data yang ada.
Solusinya adalah memanfaatkan stored procedure di MySQL, dan aplikasi PHP kita cukup terima data mateng hasil perhitungan stored procedure bersangkutan, dan Alhamdulillah berhasil menemukan solusi seperti di bawah ini. Silakan dipelajari 😀
PS C:\Users\hiday> mysql -u root
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 26
Server version: 10.5.7-MariaDB-log mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> use test
Database changed
MariaDB [test]> -- First drop sample table if already exists
MariaDB [test]> DROP TABLE if exists transaksi cascade;
Query OK, 0 rows affected (0.009 sec)
MariaDB [test]> -- Create our test table
MariaDB [test]> CREATE TABLE transaksi as
-> select 'CN235' kode, '2012-01-02' tanggal, 100 nilai union all
-> select 'N2130' kode, '2012-01-02' tanggal, 120 nilai union all
-> select 'CN235' kode, '2012-01-11' tanggal, 140 nilai union all
-> select 'CN235' kode, '2012-01-11' tanggal, 150 nilai union all
-> select 'CN236' kode, '2012-01-11' tanggal, 200 nilai union all
-> select 'CN235' kode, '2012-01-15' tanggal, 160 nilai union all
-> select 'CN235' kode, '2012-01-17' tanggal, 170 nilai union all
-> select 'CN235' kode, '2012-01-17' tanggal, 180 nilai union all
-> select 'N2130' kode, '2012-01-15' tanggal, 200 nilai union all
-> select 'CN236' kode, '2012-01-11' tanggal, 400 nilai union all
-> select 'CN236' kode, '2012-01-15' tanggal, 120 nilai union all
-> select 'CN236' kode, '2012-01-17' tanggal, 400 nilai union all
-> select 'N2130' kode, '2012-01-17' tanggal, 600 nilai union all
-> select 'CN236' kode, '2012-01-02' tanggal, 800 nilai
-> ;
Query OK, 14 rows affected (0.018 sec)
Records: 14 Duplicates: 0 Warnings: 0
MariaDB [test]> -- First drop if the procedure already exists
MariaDB [test]> DROP PROCEDURE if exists crosstab_transaksi;
Query OK, 0 rows affected (0.007 sec)
MariaDB [test]> -- Now create our stored procedure
MariaDB [test]> DELIMITER $$
MariaDB [test]> CREATE PROCEDURE crosstab_transaksi()
-> BEGIN
-> -- declare variables
-> declare prepsql varchar(1000);
-> declare summsql varchar(1000);
-> declare totalsql varchar(100);
-> -- generate summary clause
-> select group_concat(' sum(case when tanggal=\'',tanggal,'\' then nilai else 0 end) as "',tanggal,'"\n')
-> into summsql
-> from ( select distinct tanggal from transaksi order by tanggal ) tx;
-> -- generate full sql query
-> set totalsql = ', sum(nilai) as total\n';
-> set prepsql = concat('select kode,',summsql,totalsql,'from transaksi group by kode');
-> -- executing generated query
-> set @mysql = prepsql;
-> prepare stmt from @mysql;
-> execute stmt;
-> -- clean up
-> drop prepare stmt;
-> END$$
Query OK, 0 rows affected (0.007 sec)
MariaDB [test]> DELIMITER ;
MariaDB [test]> -- Let see our sample data
MariaDB [test]> SELECT * from transaksi
-> ORDER BY kode, tanggal;
+-------+------------+-------+
| kode | tanggal | nilai |
+-------+------------+-------+
| CN235 | 2012-01-02 | 100 |
| CN235 | 2012-01-11 | 140 |
| CN235 | 2012-01-11 | 150 |
| CN235 | 2012-01-15 | 160 |
| CN235 | 2012-01-17 | 180 |
| CN235 | 2012-01-17 | 170 |
| CN236 | 2012-01-02 | 800 |
| CN236 | 2012-01-11 | 200 |
| CN236 | 2012-01-11 | 400 |
| CN236 | 2012-01-15 | 120 |
| CN236 | 2012-01-17 | 400 |
| N2130 | 2012-01-02 | 120 |
| N2130 | 2012-01-15 | 200 |
| N2130 | 2012-01-17 | 600 |
+-------+------------+-------+
14 rows in set (0.001 sec)
MariaDB [test]> -- And then call our stored procedure to get the summary
MariaDB [test]> CALL crosstab_transaksi;
+-------+------------+------------+------------+------------+-------+
| kode | 2012-01-02 | 2012-01-11 | 2012-01-15 | 2012-01-17 | total |
+-------+------------+------------+------------+------------+-------+
| CN235 | 100 | 290 | 160 | 350 | 900 |
| CN236 | 800 | 600 | 120 | 400 | 1920 |
| N2130 | 120 | 0 | 200 | 600 | 920 |
+-------+------------+------------+------------+------------+-------+
3 rows in set (0.001 sec)
Query OK, 1 row affected (0.012 sec)
MariaDB [test]>
Secara umum alur dari stored procedure di atas adalah:
Script yang diperlukan untuk membuat stored procedure nya adalah sebagai berikut,
-- Now create our stored procedure
DELIMITER $$
CREATE PROCEDURE crosstab_transaksi()
BEGIN
-- declare variables
declare prepsql varchar(1000);
declare summsql varchar(1000);
declare totalsql varchar(100);
-- generate summary clause
select group_concat(' sum(case when tanggal=\'',tanggal,'\' then nilai else 0 end) as "',tanggal,'"\n')
into summsql
from ( select distinct tanggal from transaksi order by tanggal ) tx;
-- generate full sql query
set totalsql = ', sum(nilai) as total\n';
set prepsql = concat('select kode,',summsql,totalsql,'from transaksi group by kode');
-- executing generated query
set @mysql = prepsql;
prepare stmt from @mysql;
execute stmt;
-- clean up
drop prepare stmt;
END$$
DELIMITER ;
Source code lengkap nya bisa dilihat di sini.
Dengan cara di atas, aplikasi hanya perlu memanggil stored procedure dan langsung mendapatkan hasil report-nya dalam bentuk “matang” tanpa perlu proses perhitungan lagi.
Selamat mencoba… 🙂
Artikel ini merupakan bagian terakhir dari 3 artikel tentang Data Access Component di lingkungan Windows. Bagian pertama membahas konsep Data Access Universal. Bagian kedua membahas lebih detail mengenai Data Access Consumers. Dan bagian ketiga membahas model data akses dalam .NET framework, atau lebih kita kenal sebagai ADO.NET. ADO.NET
Bersamaan dengan diluncurkannya .NET Framework, Microsoft memperkenalkan model akses data baru yang diberi nama ADO.NET. Singkatan ActiveX Data Object sebenarnya tidak lagi relevan karena ADO.NET bukanlah komponen ActiveX, namun merupakan model yang benar-benar baru dibangun menggunakan .NET framework. Microsoft sepertinya mempertahankan nama ADO karena kasuksesannya yang luar biasa.
ADO.NET tetap memberikan dukungan komunikasi data menggunakan ODBC dan OLE-DB, namun menawarkan pilihan lain yaitu dengan menggunakan Data Provider yang khusus dibangun untuk database tertentu. Data provider ini mampu memberikan kinerja yang lebih baik karena dapat memanfaatkan optimisasi yang ditawarkan oleh vendor database bersangkutan. Dengan menggunakan custom-code yang spesifik untuk database tertentu juga menghilangkan sejumlah overhead yang terjadi ketika menggukan generic-code seperti ODBC dan OLE-DB. Rilis awal yaitu ADO.NET 1.0, baru memberikan dukungan untuk Database SQL Server dan OLE-DB. Riils berikutnya – ADO.NET 1.1 – Microsoft menambahkan dukungan untuk database Oracle dan ODBC. Pada saat yang hampir bersamaan Oracle juga merilis data provider milik mereka sendiri, yaitu ODP.NET 9.2.
Gambar berikut ini menggambarkan cara ADO.NET bekerja.
Berbeda dengan ADO yang menawarkan konsep recordset dan cursor, ADO.NET memperkenalkan model yang benar-benar baru meliputi lima obyek dasar sebagai berikut:
ADO.NET membuat lompatan yang sangat besar. Salah satunya adalah adanya dukungan penuh untuk model akses data terputus (disconnected). Mempertahankan sebuah koneksi yang tidak tidak terputus ke database server adalah proses yang cukup mahal harganya. Terutama dari sisi database server yang mengharuskan pengalokasian sumber daya – terutama CPU dan memory – untukkoneksi tersebut. Ketika hanya ada satu koneksi saja yang perlu dipertahankan, mungkin tidak terlalu menjadi masalah, lain halnya jika koneksi yang perlu dipertahankan tidak sedikit, misalkan pada aplikasi web, tentunya jumlah memory dan CPU yang terpakai akan jauh lebih besar. Namun jika kita menggunakan metode akses data yang terputus, sumber daya yang semula terpakai dapat langsung dibebaskan dan dipakai oleh proses lain.
Fitur lain yang meningkatkan performa akses data adalah diperkenalkannya connection pooling. Mempertahankan sebuah koneksi ke database adalah proses yang mahal, namun membuka dan menutup koneksi database adalah proses yang lebih mahal lagi. Connection pooling mampu mengatasi masalah ini. Ketika koneksi yang kita buat dalam program ditutup, ADO.NET tidak langsung menutup koneksi tersebut, namun menyimpannya dalam sebuah pool sampai jangka waktu tertentu. Pada saat itu ketika ada proses yang membutuhkan koneksi, maka ADO.NET tidak perlu lagi membuat koneksi baru, namun cukup menggunakan koneksi yang sudah tersedia di pool.
Keunggulan lain dari ADO.NET adalah dukungan terhadap XML. Secara internal obyek DataSet menyimpan data di memory dalam bentuk XML. DukunganXML ini memudahkan ADO.NET dalam melakukan proses filtering dan sorting data yang tersimpan di memory. Dukungan XML juga memudahkan proses pengambilan data, penuilsan data kembali ke database dan mengubah ke dalam format lainnya.
ADO.NET 2.0
Perkembangan teknologi data akses sudah begitu canggih dengan adanya ADO.NET, namun rupanya Microsoft masih menemukan cara untuk mengembangkannya, yaitu dengan diperkenalkannya ADO.NET 2.0. Perubahan yang ada pada ADO.NET 2.0 tidak seradikal perubahan dari ADO ke ADO.NET, namun lebih berupa panambahan fitur-fitur baru, yang memudahkan para programmer dalam proses pengembangan aplikasi. Desain asal ADO.NET 2.0 masih sama dengan ADO.NET 1.x sehingga semua aplikasi yang sebelumnya dibuat menggunakan ADO.NET 1.x akan 100% kompatibel dengan ADO.NET 2.0.
Salah satu tujuan dari ADO.NET 2.0 adalah peningkatan performa. Bukan berarti performa ADO.NET 1.x buruk, namun peningkatan dapat dilakukan misalnya dengan tambahan dukungan penulisan data beberapa row sekaligus (bulk insert) yang sebelumnya harus dilakukan satu persatu.
Fitur yang tambahan lainnya adalah notifikasi ketika ada perubahan data di database. Fitur lainnya adalah dukungan Multiple Active Result Sets (MARS), dengan cara ini, dengan satu query dapat memberikan beberapa hasil sekaligus, sehingga mengurangi proses komunikasi antar aplikasi dengan database.
ADO.NET 2.0 juga memudahkan programmer untuk membuat aplikasi yang mendukung beberapa produk database dengan menggunakan satu coding saja, artinya coding yang sama mampu mendukung beberapa sistem database sekaligus. Hal ini sangat berguna sekali ketika kita ingin apilkasi ini tidak hanya mendukung satu sistem database saja. Namun perlu diperhatikan, bahwa sintaks SQL tetap spesifik untuk sistem database tertentu, misalkan sintaks Transact-SQL di SQL Server tidak bisa dijalankan di Oracle.
ADO.NET 3.0
ADO.NET 3.0 dirilis bersamaan dengan dirilisnya Visual Studio 2008 sebagai bagian dari .NET framework 3.5. Ada loncatan pada versi .NET framework dikarenakan .NET framework 3.0 sebelumnya sudah dirilis sebagai bagian dari Windows Vista, namun versi ADO.NET pada framework 3.0 masih versi 2.0. Salah satu fitur utama dari ADO.NET 3.0 adalah Object Relational Mapping (ORM) dan Language Integration Query (LINQ). Dengan menggunakan OR/M dan LINQ memungkinkan kita mengakses data secara lebih mudah dan transaparan. Sebagai contoh, dalam .NET 2.0 kita masih sibuk dengan proses buka tutup koneksi ke database, maka hal ini tidak akan terlihat lagi dalam .NET 3.0 berkat fitur ORM dan LINQ ini.
Dikarenakan cukup panjangnya bahasan mengenai ORM dan LINQ, maka saya pikir akan kita bahas lebih detail dalam artikel-artikel berikutnya, namun untuk informasi lebih lanjut Anda dapat mengunjungi website Microsoft di http://msdn.microsoft.com/data/ref/linq/
Selesai…
Artikel ini merupakan bagian kedua dari 3 artikel tentang Data Access Component di lingkungan Windows. Bagian pertama membahas konsep Data Access Universal, bagian kedua membahas lebih detail mengenai Data Access Consumers, dan bagian ketiga membahas model data akses dalam .NET framework.
Data Access Consumers
Para programmer yang menggunakan bahasa yang mendukung pointer – seperti C, C++ dan sebagainya – dapat berkomunikasi dengan database langsung menggunakan API yang disediakan ODBC atau OLE-DB. Namun untuk programmer yang menggunakan bahasa pemrograman yang tidak mendukung pointer – seperti Visual Basic -memerlukan lapisan lain. Disinilah DAO, RDO, ADO, and ADO.NET dapat berperan.
DAO
Bersamaan dengan diluncurkannya Visual Basic 2.0, para programmer diperkenalkan dengan sebuah metode akses data baru yang dikenal sebagai Data Access Objects (DAO). Ini adalah usaha pertama Microsoft membuat Data Access Consumer. Walaupun versi awal kemampuannya sangat terbatas, Namun ini adalah awal sejumlah library yang memudahkan programmer dalam mengakses data karena sangat membantu programmer dengan bahasa tingkat tinggi seperti Visual Basic untuk memanfaatkan keunggulan ODBC. Sebelumnya ODBC API hanya bisa diakses melalui bahasa dengan elvel lebih rendah seperti C dan C++.
DAO dikembangkan menggunakan library JET. JET sendiri adalah library/engine yang digunakan oleh Microsoft untuk membangun aplikasi database Microsoft Access. DAO bersungsi sebagai lapisan yang menghubungkan aplikasi dengan database itu sendiri. Tujuannya tentu untuk memudahkan kerja programmer.
Varsi awal dari DAO ini sudah dimasukkan dalam paket pemrograman Visual Basic 2.0, namun secara resmi baru diberikan nama DAO 1.0 ketika Microsoft Access 1.0 diluncurkan. Versi ini baru mendukung koneksi langsung ke database Access dan ODBC. Versi 2.0 kemudian diluncurkan untuk mendukung OLE-DB dan versi 2.5 dan 3.0 juga akhirnya diluncurkan untuk mendukung ODBC 2.0 dan sistem operasi 32-bit yang baru diluncurkan, Windows 95.
Gambar berikut ini menunjukkan bagaimana DAO bekerja.
Namun ada satu kelemahan mendasar yang dimiliki oleh DAO, yaitu DAO hanya dapat berkomunikasi langsung dengan JET engine. Untuk mengakses database selain Microsoft Access menggunakan ODBC maka harus berkomunikasi dahulu dengan JET engine. Hal ini membuat kinerja DAO dianggap kurang memuaskan.
RDO
Remote Data Objects (RDO) adalah upaya Microsoft mengatasi lambatnya kinerja DAO. Saat perlu mengakses database selain MS Access maka RDO langsung berkomunikasi dengan ODBC tanpa menggunakan JET engine. Dengan cara ini kinerja RDO jauh meningkat dibandingkan dengan DAO. JET hanya digunakan ketika akan mengakses database MS Access.
Gambar berikut menunjukkan bagaimana RDO bekerja.
Hal lain yang menjadi keunggulan RDO adalah fitur client-side cursor saat melakukan navigasi data. Berlawanan dengan DAO yang hanya mendukung server-side cursor. Fitur ini mampu mempercepat kinerja aplikasi dan mengurangi beban koneksi aplikasi pada server database.
Namun secara umum RDO tidak mendapatkan tanggapan yang serius dari para pengembang perangkat lunak. RDO utamanya ditujukan untuk bagi customer komersil untuk membangun aplikasi berskala enterprise, serta bagi para pengembang yang tidak mau menggunakan DAO karena kinerjanya yang buruk. Dengan alasan ini RDO hanya tersedia pada Visual Basic Enterprise Edition. Akibatnya tidak semua programmer memiliki akses untuk memanfaatkannya. Programmer yang membangun aplikasi kecil yang tidak terlalu bermasalah dengan kinerja juga enggan berpindah ke RDO. Ditambah lagi dengan diluncurkannya ODBCDirect – sebuah add-on untuk DAO yang mampu meningkatkan kinerja DAO – membuat popularitas RDO semakin berkurang di kalangan pengembang perangkat lunak.
ADO
Microsoft memperkenalkan ActiveX Data Objects (ADO) untuk menyediakan API dengan level yang lebih tinggi saat memanfaatkan OLE-DB untuk berkumonikasi dengan database. Microsoft juga belajar banyak dari pengalaman sewaktu mengembangkan DAO dan RDO untuk membuat API yang lebih ringan, dan lebih efisien. ADO ditujukan untuk menggantikan DAO dan RDO. Pada saat awal diluncurkan ADO (dan OLE-DB) diyakini sebagai solusi untuk mengakses berbagai macam database sampai email, file teks bahkan spreadsheet.
ADO juga memperkenalkan metode baru dalam mengakses database. Pada masa DAO dan RDO, para programmer harus mengerjakan beberapa langkah yang cukup rumit sebelum bisa menjalankan sebuah perintah sederhana. Sebagai contoh, untuk menjalanakan sebuah perintah SQL dalam RDO, programmer tidak bisa serta merta membuat obyek rdoQuery, tapi sebelumnya hanrus membuat obyek rdoEngine, kemudian rdoEnvironment sebagai child-nya, kemudian rdoConnection baru kemudian obyek rdoQuery bisa dibuat. Dalam DAO situasinya tidak jauh berbeda. Dalam ADO, semua langkah-langkah ini dipermudah. Programmer dapat langsung membuat obyek command dengan memberikan parameter connection dan langsung menjalankannya. Obyek command bahkan dapat berdiri sendiri walaupun obyek connection belum dibuatkan.
Salah satu kelebihan lain adalah ADO menyediakan provider model. Provider model membuat ADO mampu berkomunikasi dengan sumber data selain OLE-DB. Model ini juga memudahkan pengembang perangkat lunak independen membuat provider mereka sendiri, provider ini nantinya akan digunakan ADO untuk berkomunikasi dengan sumber data bersangkutan. Sebagai contoh adalah provider ODBC. Ketika programmer ingin menakses sember data ODBC, maka ADO akan berkomunikasi langsung dengan ODBC, tidak melalui OLE-DB. Metode akses langsung ini semakin meningkatkan kinerja yang diberikan ADO dibandingkan dengan Data Consumer pendahulunya.
Gambar berikut menunjukkan bagaimana ADO bekerja.
ADO juga memberikan sejumlah kemudahan bagi para programmer yang merasa kesulitan dengan model akses data yang diberikan DAO dan RDO. Kemudahan itu antara lain adalah:
Walaupun begitu banyak perbaikan yang ditawarkan ADO, bukan berarti tidak memiliki kelemahan. Sebagai contoh adalah dukungan Disconnected Data Access yang tidak terkalu populer dikalangan programmer, bahkan mungkin ada yang tidak mengetahuinya. Para programmer lebih memilih untuk membiarkan koneksi database tetap terbuka sambil melakukan perubahan terhadap data.
Para programmer yang mencoba langsung menutup koneksi database setelah mengambil data mendapati bahwa mereka harus membuka kembali koneksi database kembali untuk meneruskan perubahan data di memori secara permanen ke database. Proses buka tutup koneksi database ini rupanya merupakan proses yang cukup memakan waktu sehingga justru menurunkan kinerja aplikasi secara keseluruhan. Sebagai akibatnya, para programmer lebih memilih membiarkan satu koneksi ke database tetap terbuka dan memanfaatkan koneksi ini untuk semua proses akses database pada aplikasi.
Bersambung ke bagian III (ADO.NET)
Pelajaran sejarah adalah salah pelajaran favoritku di sekolah, kecuali PSPB :-). Dalam artikel ini saya akan mencoba membahas sejarah perkembangan model komponen data akses (Data Access Component) di lingkungan Windows dan bagaimana evolusinya sampai sekarang… eh… evolusi kan pelajaran biologi ya? bukan sejarah… halah… Artikel ini terbagi menjadi 3 bagian dengan bagian pertama membahas konsep Data Access Universal, bagian kedua membahas lebih detail mengenai Data Access Consumers, dan bagian ketiga membahas model data akses dalam .NET framework. Selamat membaca…
Sejarah Singkat Data Access Universal
Pada awalnya tidak ada keseragaman metode dalam mengakses data. Setiap sistem database memiliki API (Application Programming Interface) dan metode aksesnya sendiri-sendiri. Sebagai contoh Clipper dan Foxpro pada masa DOS, masing masing memiliki bahasa pemrogramannya sendiri, kalaupan ada kesamaan tidaklah terlalu banyak. Kelihatannya tidak terlalu sulit, setiap programmer hanya perlu memahami semua fungsi dalam API database yang dipakainya. Kesulitannya adalah ketika perlu berpindah ke sistem database yang lain. Pengetahuan tentang sistem database lama seakan tidak diperlukan lagi karena harus mempelajari sistem database yang baru dari awal lagi. Lama kelamaan hal seperti ini tidak lagi bisa dilakukan karena semakin banyaknya vendor yang menawarkan sistem database mereka sendiri, dengan segala kelebihan dan kekurangannya tentunya. Sulit bagi programmer untuk bisa memahami seluruhnya kecuali ada semaram standarisasi dalam metode akses database yang berbeda-beda tersebut. Berikut ini adalah standarisasi yang dilakukan dalam platform Windows.
ODBC
Open Database Connectivity (ODBC) membantu programmer memanfaatkan berbagai sistem database tanpa perlu mengetahui detil API yang dari sistem database bersangkutan. Untuk dapat mencapai ini ODBC menyediakan model akses databasenya dan semua vendor sistem database cukup mengimplementasikan model akses tersebut sehingga ODBC dapat mengakses sistem database bersangkutan. Implementasi model akses database ini biasa kita sebut sebagai driver. Dengan cara ini programmer hanya perlu mengetahu API dari ODBC saja untuk dapat mengakses bermacam-macan sistem database.
Dengan cara seperti ini, para programmer dapat dengan mudah berpindah dari satu sistem database ke sistem database lainnya dan memanfaatkan ketrampilan yang sudah mereka dapatkan sebelumnya. Lebih jauh lagi, programmer bisa membuat aplikasi yang tidak terikat pada satu sistem database tertentu. Pendekatan ini baik untuk aplikasi yang dibuat untuk konsumsi umum karena memberikan kebebasan bagi customer bersangkutan dalam memilih sistem database yang akan mereka gunakan, bisa jadi customer bersangkutan sudah menginvestasikan dana cukup besar untuk sistem database tertentu dan tidak ingin mengluarkan dana lagi untuk membeli sistem database lainnya.
ODBC adalah sebuah lompatan besar dalam mempermudah pengembangan aplikasi database. Namun bukan berarti tanpa kelemahan. Pertama, ODBC hanya mendukung akses untuk data yang terstruktur seperti sistem database relational. Untuk data yang tidak terstruktur, atau data dengan sistem hirarki seperti LDAP, kita tidak bisa menggunakan ODBC. Kedua, ODBC hanya dapat menangani perintah SQL, sebagai standar, dan hasilnya harus dapat direpresentasikan dalam bentuk baris dan kolom. Tapi secara umum ODBC bisa dikatakan sukses besar jika dibandingkan dengan kondisi sebelum ODBC diperkenalkan…
OLE DB
Object Linking and Embedding Database (OLE-DB) adalah langkah berikutnya dalam standarisasi metode akses database, dan masih banyak sekali digunakan saat ini. OLE-DB merupakan aplikasi dari pengetahuan yang didapatkan saat mengembangkan ODBC untuk membuat model akses data yang lenih baik. OLE-DB juga menandai perubahan strategi Microsoft untuk menggunakan API berbasis COM sehingga memudahkan OLE-DB digunakan dalam berbagai macam bahasa pemrograman, sekaligus perpindahan ke sistem operasi 32-bit dengan diluncurkannya Windows 95.
Seperti umumnya sebuah program, ODBC menjadi semakin besar dan gemuk karenaberbagai macam perbaikannya. Sedangkan API yang disediakan OLE-DB jauh lebih ringkas serta memberikan performa yang lebih baik dibandingkan ODBC. Uniknya, saat pertama kali diluncurkan, OLE-DB hanya memberikan provider untuk ODBC. Provider OLE-DB untuk ODBC ini hanya sebuah wrapper terhadap API ODBC dan tidak memberikan perbaikan kinerja. Hal ini rupanya ditujukan agar para programmer menjadi terbiasa dengan API yang baru, sambil menunggu tersedianya provider yang lebih efisien dibuat untuk mengakses sistem database langsung tanpa melaui ODBC.
OLE-DB Providers
OLE-DB tidak terlalu bergantung pada struktur fisik sistem database yang diaksesnya, sehingga OLE-DB dapat mendukung sumber database relasional maupun hirarki. OLE_DB juga tidak mengharuskan query dalam bentuk SQL. OLE-DB terbagi dalam 2 bagian, yaitu OLE-DB Provider dan OLE-DB Consumer. ODBC mengharuskan para vendor database membuat provider khusus untuk sistem database mereka, dan ini bukan pekerjaan mudah. Namun dalam OLE-DB, jauh lebih mudah untuk membuat provider kita sendiri dengan format sumber data yang kita tentukan sendiri. Sebuah provider OLE-DB hanya perlu melakukan 4 langkah berikut ini:
OLE-DB Consumers
Bagian kedua dari OLE-DB framework adalah OLE-DB consumer. Bagian ini merupakan lapisan yang berkominikasi langsung dengan provider. Lapisan ini malukan langkah-langkah berikut:
Gambar berikut menunjukkan bagaimana OLE-DB bekerja.
Bersambung ke bagian II (OLE DB Consumers)
Banyak sekali setting dan konfigurasi yang dapat diubah untuk Oracle Database XE, bahkan sama banyaknya dengan edisi Enterprise-nya. Namun untuk memudahkan pengguna, kebanyakan setting dan konfigurasi tersebut sudah ditentukan sebelumnya (pre-configured), namun ada sejumlah hal yang konfigurasi umum yang akan kita bahas di sini.
Pada artikel sebelumnya Sudah dijelaskan tentang Oracle Database XE. Mudah-mudahan Anda sudah mencoba mengunduh dan menginstallnya. Untuk menguji hasil instalasi Oracle Database XE pada komputer Anda, lakukanlah sejumlah langkah-langkah berikut ini:
Mengkonfigurasi Alokasi Memori
Oracle XE dapat berjalan dengan lancar pada komputer dengan memori hanya 512 dengan sistem operasi Windows XP. Secara default biasanya Oracle akan mengalokasikan ± 128MB sebagai System Global Area (SGA). Langkah ini mungkin perlu Anda lakukan jika Anda memiliki kapasitas memori yang terbatas, atau Anda hanya ingin mengalokasi memori bebas yang lebih besar untuk menjalankan program lain, seperti Visual Studio IDE.
Sebelum kita berlanjut lebih jauh, ada baiknya jika kita terlebih dahulu memperjelas bagaimana oracle mengalokasikan memori sistem. Seperti yang sudah disebutkan di awal bab ini, ketika sebuah instance database oracle berjalan, maka oracle akan mengalokasikan memori untuk bebrapa keperluan, pertama adalah memori untuk menjalankan program-program yang residen di background, kedua adalah memori untuk SGA, dan ketiga adalah memori untuk Program Global Area (PGA).
System Global Area (SGA) bagian memori yang akan digunakan secara berbagi pakai di antara semua user yang terkoneksi ke database. Data berbagi pakai ini misalnya adalah buffer cache yang berisikan data dalam yang paling sering digunakan, serta shared pool yang berisikan perintah-perintah SQL yang sering digunakan. SGA dialokasikan pada saat database pertama kali dijalankan dan memiliki nilai maksimum. Perubahan terhadap nilai maksimum SGA baru akan berpengaruh setelah database di-restart.
Untuk mengubah target SGA, lakukanlah langkah-langkah berikut ini:
Sedangkan Program Global Area (PGA) adalah bagian memori yang dialokasikan untuk setiap sesi atau koneksi database dan berisikan informasi khusus milik sesi atau koneksi bersangkutan. Salah satu penggunaan yang umum adalah untuk melakukan sorting terhadap data yang diminta oleh user bersangkutan. Nilai dari PGA bukanlah nilai maksimum seperti halnya SGA, namun lebih berupa target total akumulai memori yang dialokasikan untuk semua sesi atau koneksi database. Kalaupun kemudian alokasinya melebihi target, maka oracle sebisa mungkin akan mengubahnya sampai mendekati target. Perubahan terhadap nilai PGA akan langsung berpengaruh pada saat sesi atau koneksi berikutnya.
Untuk mengubah target PGA, lakukanlah langkah-langkah berikut ini:
Mengaktifkan User HR
Schema atau user HR adalah contoh schema yang disediakan secara default pada semua edisi Database Oracle. Secara default schema ini terkunci (locked) sehingga kita harus mengaktifkannya terlebih dahulu sebelum dapat menggunakannya. Untuk mengaktifkan schema HR lakukanlah langkah-langkah berikut ini:
Login sebagai user HR
Untuk menguji apakah user HR sudah benar-benar aktif, maka kita dapat mencoba untuk login ke database menggunakan user HR.
Ada sedikit perbedaan pada Database Home Page yang tampil ketika kita login sebagai HR, yaitu munculnya icon Application Builder. Icon ini tidak muncul ketika kita login sebagai user SYSTEM atau SYS.
Application Express adalah sebuah lingkungan pengambangan aplikasi dekalaratif (development environtment) yang di-hosting dalam Oracle Database untuk membuat aplikasi database berbasis web. Application Express bersifat deklaratif karena tidak memperkenalkan bahasa pemrograman baru, dan saat kita membangun aplikasi web menggunakan Application Express kita hanya perlu menentukan data yang akan ditampilkan beserta posisinya pada halaman web – deklaratif. Semua informasi ini akan disimpan sebagai metadata dalam database Oracle.
Ketika aplikasi dijalankan, secara realtime, engine Application Express akan membaca metadata yang tersimpan dalam database tersebut dan merender halaman web sesuai dengan deklarasi yang kita buat sebelumnya.
Saya akan membahas lebih jauh mengenai Application Express dalam posting-posting selanjutnya. Untuk mengetahui lebih lanjut mengenai Application Express, Anda dapat melihatnya di http://otn.oracle.com/apex/