Membangun Aplikasi Sistem Informasi Dengan Kecepatan Optimal
Posted by kentaro17 | 9:11 AM | Sistem Infromasi | 0 comments »


Studi Kasus: Sistem Informasi dengan Delphi 5 dan database PostgreSQL

by: Agus Widodo, S.Kom

Kecepatan yang saya maksudkan di sini adalah kecepatan aplikasi (*.exe) yang akan di-’nikmati’ oleh user/pengguna aplikasi. Bukan kecepatan seorang programmer untuk menghasilkan sebuah form seperti halnya rapid application development (RAD) yang akan dinikmati oleh programmer.

Mengapa Harus Cepat?

Kecepatan program bagi seorang programmer menunjukkan juga kecakapan memproduksi aplikasi (coding) dengan cara yang tepat. Ingat! Proses adalah sebagian dari hasil. Hasil bagus pastilah terlahir dari proses yang matang, bagus, terencana dan tepat. Bukan kebetulan terjadi. Jika cara programming kita asal-asalan, siap-siaplah menuai kritik bahkan cemooh user: “wah kok lambat ya…”, “Masa untuk proses data harus di tinggal makan siang dulu mas…”

Itu dari sudut programmer, bagi sudut corporate/company (dengan jumlah record transaksi yang besar), maka program yang robust dengan kecepatan handal adalah kebutuhan. Misalkan saja sebuah kasir pitstop sebuah depo container dengan antrian panjang. Satu detik saja sangat berharga, klo bisa, begitu di tekan tombol print maka proses cetak langsung ke dua printer dan sebuah form siap input sudah siap di isi tanpa terpengaruh dengan loading data untuk print dsb.
Beberapa Tips Untuk Mendapatkan Kecepatan Optimal

Berikut beberapa catatan singkat yang sempat terekam saat membangun aplikasi.

1. Pilihlah jenis koneksi database yang tepat

Sebelum terlalu jauh digunakan, cobalah beberapa alternatif koneksi yang memungkinkan. Bandingkan dan pilih dengan kecepatan yang paling optimal. Biasanya, koneksi langsung (direct connection) ke database jauh lebih cepat daripada harus melewati lapisan lagi semacam ODBC. Dalam kasus yang saya temui, saya menemukan bahwa koneksi ke PostgreSQL sangat jauh lebih cepat dengan Zeos daripada PsqlODBC.

2. Gunakan DLL untuk membuat program lebih moduler

DLL’s tersebut bisa kita gunakan menimpan prosedur2 yang sering di gunakan. Ini akan membuat file exe jadi lebih kecil ukurannya. DLL bisa dipanggil hanya ketika di perlukan.

3. Open dataset pada saat yang tepat dan memang di butuhkan

Jangan pasang semua dataset pada sebuah form dan di open semua saat form onShow. Open untuk dataset yang dibutuhkan . Jika ada dataset yang mungkin tidak mesti digunakan, open saat akan dibutuhkan saja. Misal dengan :

With Table1 do
if not Active then Open;

4. Gunakan query base daripada table base untuk form transaksi yang memerlukan banyak dataset

Query bisa kita atur untuk mengambil sebagian data saja, meskipun bisa juga dengan mennggunakan TTable dan di filter. Tapi itu akan jauh lebih lambat.

Akan lebih cepat Anda melakukan query dengan :

Insert into customer (nik,...) values ('0001' ... ...)

daripada:

Table1.Append;
Table.FieldByName(’nik’).AsString := ‘0001′;

Dengan query maka client tidak perlu meminta seluruh data (seperti pada table). Performance program akan terjaga. Jika menggunakan cara kedua (TTable), setiap bertambah record itu sama artinya menurunkan performance, semakin lama semakin lambat.

5. Load data sesuai yang diinginkan

Jika form hanyalah untuk input, maka gunakan komponen non DataAware, maksudnya komponen yang tidak berhubungan langsung dengan koneksi database missal TEdit (TDBEdit). Jadi begitu input langsung masukkan pada property SQL.Text := 'insert into ... bla... bla...'

Pilihlah Memory Table daripada TQuery yang dipasangkan dengan TUpdateSQL untuk menqoperasikan sebagian hasil query untuk di edit. Jangan pake Table yang di filter! Ini sama artinya meminta aplikasi load all data kemudian di pilihi.

7. Bijaksanalah menggunakan CalculatedField

Pilihlah query yang cukup kompleks untuk ambil dari beberapa table daripada Anda open satu dataset kemudian menggunakan event onCalculated, yang akan mengisikan field Calculated. Karena onCalculated akan terus di eksekusi sebanyak record yang harus di load. Jika query maka server hanya sekali menerima perintah, di proses dan kirim lagi. Ini juga akan mengurangi beban jaringan daripada cara CalculatedField.
Output Program

1. Cetak Ke Layar
Jika dataset sudah tersedia maka jangan pilih report dengan koneksi langsung ke database seperti crytal report tapi pilih reporting tool yang bisa ambil data dari dataset yang sudah terisi pada form.
Jika dataset tidak tersedia (biasanya kita masukkan dalam menu laporan input parameter laporan), baru menggunakan report yang akan mengquery data
Jika ingin mengeluarkan output ke office document seperti excel, jangan gunakan OleContainer tapi gunakan excel report tool (banyak VCL yang free). OleContainer akan meminta program handle dokumen yang dihasilkan. Ini salah satu (diagnosa saya) yang menyebabkan kadang terasa sangat lambat untuk pasing data. Lain dengan Excel Report yang hanya open excel dan create dokumen, lempar data.
Jika ada penghitungan, sorting, dan gruping, pilihlah option untuk hitung di server, tentunya saya memakai asumsi bahwa computer server memang di sediakan untuk operasi data dengan cepat dan handal.
Untuk laporan yang menggunakan image (misal foto) yang tersimpan. Batasi ukuran file saat penyimpanan saja. Sehingga saat laporan tidak memberatkan.

2. Pencetakan
Pilih print langsung ke printer jika memang tidak memerluka print via jaringan.
Gunakan Thread untuk open koneksi dataset untuk dataset yang aman. Thread memungkinan membuka dataset secara bersamaan dalam satu waktu. Jadi tidak sekuensial. Akan tetapi, ini akan menjadi ‘petaka’ manakala kita tidak hati2 dengan mengecek status opennya saat akan menggunakan. karena meski dataset belum open, form sudah bisa di lihat user.
Browse Data dan UI

1. Minimalisasi penggunaan mouse
Gunakan shortcut
Pemakaian tombol2 yang tepat. Jangan meminta user untuk menekan/klik tombol jika memang transaksi bisa dilakukan tanpa melakukannya. Contoh tombol Add/Edit
Minimalisasi browse data dengan jumlah besar. Lebih cepat validasi data setelah user input. Browse data hanya digunakan untuk pencarian jika user memang tidak memegang data transaksi secara jelas(masih perlu proses pencarian).
Jika memerlukan browse data, usahakan untuk meminimalisi query dengan minta bantuan user menginput sebagian data. (gunakan ‘ilike’)

2. Efisiensi coding
Efisiensikan pemakaian variable pada coding, karena semakin tidak efisien semakin memeberatkan memory. Juga perhatikan coding kita, jangan terburu2 membuat looping yang memerlukan variable jika sebenarnya tidak perlu.
Jangan terlalu banyak memakai komponen yang bermacam-macam dari VCL yang berbeda-beda. Ingat semakin banyak unit (kita deklarasikan dengan frasa Uses) akan semakin membuat ukuran file kita besar dan aka mengurangi performance. Misal, klo sudah pakai Developer Express, maka untuk grid, editor2 nya usahakan sama saja. Kecuali memang ada tujuan betul2 khusus. Jika Anda mengganti komponen (menghapusnya dan menggantikan dengan lainnya), usahakan untuk cek di Uses jangan sampai unit2nya masih tertempel terus pada form Anda.
Jika Anda menggunakan Skin (seperti SuiSki / Dynamic Skin Form) untuk mempercantik tampilan, sertakan file skin dengan exe. Lebih baik tidak di buat built in. ini menghindari ukuran aplikasi yang membengkak. Jangan lupa untuk men-skin form hanya untuk form itu saja.

Jika ada catatan saya yang salah, sudilah kiranya saya diberi pencerahan ke email langsung. Terima kasih sebelumnya