Senin, 11 Juli 2011
Jumat, 08 Juli 2011
Contoh Surat Lamaran Kerja
Attention To:
HRD Manager
Muhammadiyah University Of Purwokerto
Jl. Raya Dukuhwaluh
Purwokerto
Dear Sir/Madam,
I have read from your advertisement at Kompas that your university is looking for lecturer. Based on the advertisement, I am interested in applying application for Engineer position according with my background educational as Informatic Engineering.
My name is Susilo Utomo, I am twenty years old. I have graduated from Informatic Engineering of Department on March 2007. My specialization in Informatic Engineering. I consider myself that I have qualifications as you want. I have good motivation for progress and growing, eager to learn, and can work with a team (team work) or by myself. Beside that I posses adequate computer skill and have good command in English (oral and written).
With my qualifications, I confident that I will be able to contribute effectively to university. Herewith I enclose my :
1. Copy of Bachelor Degree (S-1) Certificate and Academic Transcript.
2. Curriculum Vitae.
3. Copy of Job Training Certificate from Unocal Indonesia Company.
4. Recent photograph with size of 4x6
I would express my gratitude for your attention and I hope I could follow your recruitment test luckily.
Sincerely yours,
Susilo Utomo
____________________________________________________________________________________
Perhatian Untuk:
HRD Manajer
Muhammadiyah University Of Purwokerto
Jl. Raya Dukuhwaluh
Purwokerto
Dear Sir / Madam,
Saya telah membaca dari iklan Anda di Kompas bahwa universitas Anda sedang mencari dosen. Berdasarkan iklan, saya tertarik dalam menerapkan aplikasi untuk posisi Insinyur sesuai dengan latar belakang saya pendidikan sebagai Teknik Informatika.
Nama saya Susilo Utomo, saya dua puluh tahun. Saya telah lulus dari Teknik Informatika Departemen pada Maret 2007. Saya spesialisasi di bidang Teknik Informatika. Saya menganggap diri saya bahwa saya memiliki kualifikasi seperti yang Anda inginkan. Saya memiliki motivasi yang baik untuk kemajuan dan berkembang, bersemangat untuk belajar, dan dapat bekerja dengan tim (team work) atau sendiri. Selain itu saya dimiliki keterampilan komputer yang memadai dan memiliki perintah yang baik dalam bahasa Inggris (lisan dan tertulis).
Dengan kualifikasi saya, saya yakin bahwa saya akan dapat memberikan kontribusi secara efektif ke universitas. Dengan ini saya saya melampirkan:
1. Copy Sarjana (S-1) Sertifikat dan Transkrip Akademik.
2. Kurikulum Vitae.
3. Copy Sertifikat Kerja Praktek dari Unocal Indonesia Company.
4. Foto terakhir dengan ukuran 4x6
Saya akan mengungkapkan rasa terima kasih atas perhatian dan saya berharap bisa mengikuti tes rekrutmen untungnya Anda.
Hormat kami,
Susilo Utomo
HRD Manager
Muhammadiyah University Of Purwokerto
Jl. Raya Dukuhwaluh
Purwokerto
Dear Sir/Madam,
I have read from your advertisement at Kompas that your university is looking for lecturer. Based on the advertisement, I am interested in applying application for Engineer position according with my background educational as Informatic Engineering.
My name is Susilo Utomo, I am twenty years old. I have graduated from Informatic Engineering of Department on March 2007. My specialization in Informatic Engineering. I consider myself that I have qualifications as you want. I have good motivation for progress and growing, eager to learn, and can work with a team (team work) or by myself. Beside that I posses adequate computer skill and have good command in English (oral and written).
With my qualifications, I confident that I will be able to contribute effectively to university. Herewith I enclose my :
1. Copy of Bachelor Degree (S-1) Certificate and Academic Transcript.
2. Curriculum Vitae.
3. Copy of Job Training Certificate from Unocal Indonesia Company.
4. Recent photograph with size of 4x6
I would express my gratitude for your attention and I hope I could follow your recruitment test luckily.
Sincerely yours,
Susilo Utomo
____________________________________________________________________________________
Perhatian Untuk:
HRD Manajer
Muhammadiyah University Of Purwokerto
Jl. Raya Dukuhwaluh
Purwokerto
Dear Sir / Madam,
Saya telah membaca dari iklan Anda di Kompas bahwa universitas Anda sedang mencari dosen. Berdasarkan iklan, saya tertarik dalam menerapkan aplikasi untuk posisi Insinyur sesuai dengan latar belakang saya pendidikan sebagai Teknik Informatika.
Nama saya Susilo Utomo, saya dua puluh tahun. Saya telah lulus dari Teknik Informatika Departemen pada Maret 2007. Saya spesialisasi di bidang Teknik Informatika. Saya menganggap diri saya bahwa saya memiliki kualifikasi seperti yang Anda inginkan. Saya memiliki motivasi yang baik untuk kemajuan dan berkembang, bersemangat untuk belajar, dan dapat bekerja dengan tim (team work) atau sendiri. Selain itu saya dimiliki keterampilan komputer yang memadai dan memiliki perintah yang baik dalam bahasa Inggris (lisan dan tertulis).
Dengan kualifikasi saya, saya yakin bahwa saya akan dapat memberikan kontribusi secara efektif ke universitas. Dengan ini saya saya melampirkan:
1. Copy Sarjana (S-1) Sertifikat dan Transkrip Akademik.
2. Kurikulum Vitae.
3. Copy Sertifikat Kerja Praktek dari Unocal Indonesia Company.
4. Foto terakhir dengan ukuran 4x6
Saya akan mengungkapkan rasa terima kasih atas perhatian dan saya berharap bisa mengikuti tes rekrutmen untungnya Anda.
Hormat kami,
Susilo Utomo
Selasa, 05 Juli 2011
Replication
Melakukan copy dari 1 atau lebih server (disebut sebagai Replicas) demi availability dan performance yang lebih baik.
Keputusan yang salah dalam menentukan arsitektur Replikasi, bisa berarti :
worse performance – suatu “update” harus di-apply kesemua Replicas dan disinkronisasi
worse availability – beberapa algoritma membutuhkan banyak Replicas untuk beroperasi, padahal dalam kenyataan hanya beberapa diantaranya yang digunakan
Snapshot Replication
Mencopy semua data dari ARTIKEL ke SUBSCRIBER
Mengabaikan data yang telah dimodifikasi di SUBSCRIBER (subscriber menjadi Read Only)
Network Bandwidth yang dibutuhkan sangat besar
Mudah implementasinya
Proses Copy Artikel terjadi dalam suatu waktu
Transactional Replication
Proses Copy Transaksi dari Artikel, dengan memanfaatkan Transaction Log milik Publication DB
Setiap perubahan data yang terjadi akan dicopy dulu ke Distributor, baru kemudian dicopy ke Subscriber
Lebih efisien daripada Snapshot Replication
Traffic Network menjadi minimal (krn butuh bandwidth kecil)
Real Time
Modifikasi data di Subscriber tetap dipertahankan
Transactional publication with updatable subscriptions Replication
Seperti Transactional Replication
Bedanya, Subscriber bisa juga mempublikasi ke Pusblisher
Keputusan yang salah dalam menentukan arsitektur Replikasi, bisa berarti :
worse performance – suatu “update” harus di-apply kesemua Replicas dan disinkronisasi
worse availability – beberapa algoritma membutuhkan banyak Replicas untuk beroperasi, padahal dalam kenyataan hanya beberapa diantaranya yang digunakan
Snapshot Replication
Mencopy semua data dari ARTIKEL ke SUBSCRIBER
Mengabaikan data yang telah dimodifikasi di SUBSCRIBER (subscriber menjadi Read Only)
Network Bandwidth yang dibutuhkan sangat besar
Mudah implementasinya
Proses Copy Artikel terjadi dalam suatu waktu
Transactional Replication
Proses Copy Transaksi dari Artikel, dengan memanfaatkan Transaction Log milik Publication DB
Setiap perubahan data yang terjadi akan dicopy dulu ke Distributor, baru kemudian dicopy ke Subscriber
Lebih efisien daripada Snapshot Replication
Traffic Network menjadi minimal (krn butuh bandwidth kecil)
Real Time
Modifikasi data di Subscriber tetap dipertahankan
Transactional publication with updatable subscriptions Replication
Seperti Transactional Replication
Bedanya, Subscriber bisa juga mempublikasi ke Pusblisher
Senin, 04 Juli 2011
Transaction
Transaction Database
Dalam database management system (dbms) ada yang di sebut transaction. Transaction dalam dbms ini bertujuan untuk menggabungkan beberapa statement perubahan kedalam database menjadi dianggap satu kesatuan. Dilakukan semuanya atau tidak sama sekali (all or nothing) sehingga tidak terjadi ketidakkonsistenan data.. Transaksi mempunyai 2 fungsi utama:
1. Menyediakan reliabilitas, artinya jika terjadi kesalahan pada salah satu statement maka seluruh perubahan akan digagalkan. Sehingga data yang tersimpan benar benar reliable(dapat diandalkan).
2. Melakukan isolasi, artinya satu transaksi harus di proses satu persatu. Sehingga tidak ada kemungkinan 2 program mengakses atau bahkan mengubah data sekaligus.
Dalam transaksi ada 4 komponen utama, yaitu Atomicity, Consistency, Isolation and Durability yang biasa di singkat dengan ACID. Berikut penjelasannya:
Atomicity
Adalah suatu aturan dimana perubahan dilakukan secara keseluruhan atau tidak sama sekali. Sehingga jika di tengah transaksi terjadi kegagalan maka seruluruh perubahan akan di batalkan dan di kembalikan kekondisi semula. Kegagalan disini bisa terjadi karena aplikasi, system, database dsb.
Contoh (Ambil kasus transfer di suatu bank dari rek A ke rek B dengan nilai transfer 1000):
Maka stepnya adalah sebagai berikut:
1. Cek saldo A apakah mencukupi, jika mencukupi maka lanjut ke step ke-2. Jika tidak maka transaksi selesai dan tidak ada perubahan.
2. Kurangi saldo A sebesar 1000
3. Tambahkan saldo B sebesar 1000
Seluruh step diatas harus digabungkan sehingga apabila setelah step ke-2 terjadi kesalahan maka seluruh perubahan transaksi harus di batalkan. Setelah transaksi berhasil maka akan di lakukan commit.
Consistency
Menunjukkan konsistensi data yang ada setelah terjadi transaksi. Misalnya pada contoh kasus sebelumya, jika saldo A = 2000 dan saldo B = 500, maka setelah transaksi saldo A = 1000 dan saldo B = 1500. Nah beberapa hal yang biasanya ditangani oleh dbms adalah mengenai integrity constraint. Sedangkan jika berupa hasil perhitungan bisa di lakukan oleh aplikasi.
Isolation
Pada prinsip isolation, data yang sedang di lakukan perubahan tidak boleh diakses oleh lebih dari satu operasi. Harus hanya satu operasi yang melakukan perubahan ini. Sehingga jika ada operasi lain yang akan merubah maka harus menunggu sampai transaksi yang berlangsung selesai.
Misal ada 2 transaksi transfer antara rek A, dan rek B yang terjadi secara bersamaan:
T1 : Transfer A->B senilai 500
• Kurangi saldo A 500
• Tambah saldo B 500
T2 : Transfer B->A senilai 1000
• Kurangi saldo B 1000
• Tambah saldo A 1000
Nah bayangkan jika transaksi tersebut terjadi secara bersamaan dan di proses tanpa isolasi sehingga akan menjadi:
• Kurangi saldo A 500
• Tambah saldo B 500
• Kurangi saldo B 1000
• Tambah saldo A 1000
Jika terjadi kegagalan pada T1, maka data akan tidak konsisten sebab pada T2 sudah mengganti menambahkan saldo pada B. Demikian pentingnya isolasi, sehingga data tidak akan bisa di akses secara bersamaan oleh lebih dari satu operasi.
Durability
Kemampuan DBMS untuk menyimpan data transaksi yang terjadi. Sehingga jika terjadi kegagalan, DBMS menjamin bahwa data transaksi yang telah tersimpan tidak akan hilang. Banyak DBMS yang menuliskan log untuk suatu transaksi yang dapat digunakan ketika terjadi error pada hardware maupun software.
Salah satu poin penting dalam database transaction adalah atomic, yaitu beberapa perintah dianggap sebagai satu kesatuan. Kalau satu gagal, yang lain harus dibatalkan.
Ini adalah fundamental dari pemrograman dengan menggunakan database relasional.
Pada kasus apa perlu transaction? Ya pada semua kasus yang perlu atomic. Contohnya : header detail. Sekali insert, 1 header dan beberapa detail. Kalo pada waktu insert detail gagal, ya headernya harus diundo, kalo ngga ada header yang gantung tanpa detail sehingga datanya juga jadi salah.
Sekarang balik saya tanya, aplikasi apa yang gak pake skema header detail? Kecuali aplikasi prakarya tugas sekolah, aplikasi bisnis pasti pake header detail.
Itu masalah atomicity. Kemudian ada masalah isolation. Isolation ini artinya, transaction yang belum dicommit, tidak akan bisa dibaca oleh session lain. Contohnya gini, kita terima order 1000 item. Tentunya butuh waktu untuk menginsert 1000 record, misalnya butuh waktu 2 detik. Di dunia prosesor, 2 detik itu lama sekali, dan banyak hal bisa terjadi dalam rentang waktu tersebut. Nah, akan terjadi musibah, kalo kita ternyata ada fitur untuk menghitung jumlah order, katakan saja querynya seperti ini.
select sum(nilai) from t_order where tanggal = '2011-02-02'
yang berjalan di tengah-tengah proses insert tadi, misalnya pada waktu baru terinsert 53 order saja. Query hitung ini dijalankan oleh user lain. Suatu hal yang sangat umum terjadi, aplikasi diakses beberapa user berbarengan.
Query ini akan menghasilkan nilai yang salah, karena 1000 order itu belum tentu sukses diinsert. Misalnya pada record ke 143 terjadi mati lampu, hardisk penuh, komputer hang, browser ketutup, laptop kesiram kopi, usernya menekan tombol cancel, validasi stok produk tidak cukup, atau whatever kejadian remeh-temeh yang umum terjadi dalam kehidupan sehari-hari, tentu akan terjadi kekacauan. Karena tidak atomic, maka kita tidak tau sudah berapa record yang terinsert, sehingga menyulitkan proses recovery. Order mana yang harus diinsert ulang, dan order mana yang sudah masuk? Karena tidak ada isolation, maka user yang menjalankan perhitungan order akan mendapat hasil yang tidak sahih kebenarannya.
Seandainya saja kita menggunakan transaction dengan benar, maka pada waktu terjadi sesuatu pada waktu proses insert tadi, maka posisi database akan dikembalikan ke posisi sebelum insert dilakukan. Karena posisi sebelum insert kita tahu dengan pasti, maka recovery gampang. Insert ulang saja 1000 order tadi tanpa kecuali. Sederhana dan mudah.
Jadi kalo ada di sini yang bilang bikin aplikasi bisnis tanpa transaction, maka itu adalah nonsense. Tidak peduli kalo sampe saat ini jalan lancar, maka itu hanyalah kebetulan belaka, dan kita tidak mau selamanya mengandalkan keberuntungan kan? Kalau sampai saat ini berjalan lancar, ya mungkin aplikasinya cuma dipakai 1 concurrent user saja dan itupun jarang-jarang pake.
Nah, jadi transaction itu adalah fitur fundamental yang harus digunakan, sama seperti kalo kita keluar rumah ya harus pake celana. Di daerah lain sana orang kemana2 cuma pake koteka, dan saya tidak mau berdebat dengan mereka urusan celana. Jadi kalo masih ada yang bersikukuh bikin aplikasi bisnis gak pake transaction, ya silahkan, saya tidak mau berdebat urusan ini. Percuma berdebat sama orang yang gak pake celana ;p
Selanjutnya, sebetulnya apa benar transaction itu memberatkan aplikasi? Hmm … ini sebetulnya hanyalah mitos belaka. Yang mau mendebat silahkan sajikan benchmark antara non-transactional dan transactional. Kalo selisih performance cuma 100%, artinya kalo non-transactional cuma 2 kali lebih lemot, saya mendingan upgrade hardware daripada mengorbankan data integrity untuk gain performance yang tidak seberapa ini.
Jadi, apa kita tidak boleh pakai MyISAM ? Tentu ada waktu dan tempatnya. Data2 read only seperti misalnya tabel kategori, master produk, bolehlah pake MyISAM. Tapi kalo sudah data header detail, ya harus InnoDB dan harus menggunakan transaction supaya atomic.
Setelah kita menggunakan InnoDB, sebetulnya kita tidak bisa non-transactional. Kalo kita tidak begin dan commit secara explisit, sebenarnya untuk tiap SQL statement, itu dianggap satu transaction. Sehingga SQL seperti ini :
update table harga set nilai = nilai + 1000;
Sebetulnya akan dijalankan seperti ini ;
begin;
update table harga set nilai = nilai + 1000;
commit;
Ini namanya fitur autocommit. Di MySQL defaultnya dienable.
Dengan adanya autocommit ini, justru kita akan lebih lemot kalo tidak menggunakan transaction secara benar. Contoh, insert 100 data produk. Kalo tanpa begin dan commit explisit, berarti ada 100 begin dan ada 100 commit, artinya 100 kali menjalankan transaction. Akan lebih efisien kalo kita lakukan explisit, seperti ini :
begin;
insert into table produk (kode) values ('P-001');
... ulangi 99 kali lagi ..
commit;
Cara di atas hanya akan membutuhkan satu transaction saja. Jauh lebih efisien.
Baiklah, ada beberapa pesan moral di artikel ini
1. Header detail harus dioperasikan secara atomic
2. Operasi yang belum selesai, tidak boleh dilihat session lain, sehingga untuk aplikasi multiuser, pasti butuh isolation
3. Karena aplikasi bisnis umumnya multiuser, dan pasti punya skema header-detail, maka pasti harusmenggunakan transaction
4. Masalah performance di transaction umumnya mitos belaka, dan walaupun ada, tidak sebanding dengan mengabaikan integritas data
5. Jangan lupa pakai celana kalau keluar rumah
Pembaca setia blog saya tentu paham bahwa biasanya saya memberikan anjuran dengan kata-kata sebaiknya, tergantung situasi, dan istilah-istilah yang relatif. Tapi di artikel ini, banyak kata-kata pasti, harus, dan sejenisnya. Ini karena masalah transaction ini berkaitan dengan integritas data. Aplikasi yang kita buat haruslah bisa dipercaya untuk menghasilkan perhitungan yang benar. Tanpa menjaga integritas data dengan transaction, mustahil perhitungan yang benar bisa didapatkan.
Dalam database management system (dbms) ada yang di sebut transaction. Transaction dalam dbms ini bertujuan untuk menggabungkan beberapa statement perubahan kedalam database menjadi dianggap satu kesatuan. Dilakukan semuanya atau tidak sama sekali (all or nothing) sehingga tidak terjadi ketidakkonsistenan data.. Transaksi mempunyai 2 fungsi utama:
1. Menyediakan reliabilitas, artinya jika terjadi kesalahan pada salah satu statement maka seluruh perubahan akan digagalkan. Sehingga data yang tersimpan benar benar reliable(dapat diandalkan).
2. Melakukan isolasi, artinya satu transaksi harus di proses satu persatu. Sehingga tidak ada kemungkinan 2 program mengakses atau bahkan mengubah data sekaligus.
Dalam transaksi ada 4 komponen utama, yaitu Atomicity, Consistency, Isolation and Durability yang biasa di singkat dengan ACID. Berikut penjelasannya:
Atomicity
Adalah suatu aturan dimana perubahan dilakukan secara keseluruhan atau tidak sama sekali. Sehingga jika di tengah transaksi terjadi kegagalan maka seruluruh perubahan akan di batalkan dan di kembalikan kekondisi semula. Kegagalan disini bisa terjadi karena aplikasi, system, database dsb.
Contoh (Ambil kasus transfer di suatu bank dari rek A ke rek B dengan nilai transfer 1000):
Maka stepnya adalah sebagai berikut:
1. Cek saldo A apakah mencukupi, jika mencukupi maka lanjut ke step ke-2. Jika tidak maka transaksi selesai dan tidak ada perubahan.
2. Kurangi saldo A sebesar 1000
3. Tambahkan saldo B sebesar 1000
Seluruh step diatas harus digabungkan sehingga apabila setelah step ke-2 terjadi kesalahan maka seluruh perubahan transaksi harus di batalkan. Setelah transaksi berhasil maka akan di lakukan commit.
Consistency
Menunjukkan konsistensi data yang ada setelah terjadi transaksi. Misalnya pada contoh kasus sebelumya, jika saldo A = 2000 dan saldo B = 500, maka setelah transaksi saldo A = 1000 dan saldo B = 1500. Nah beberapa hal yang biasanya ditangani oleh dbms adalah mengenai integrity constraint. Sedangkan jika berupa hasil perhitungan bisa di lakukan oleh aplikasi.
Isolation
Pada prinsip isolation, data yang sedang di lakukan perubahan tidak boleh diakses oleh lebih dari satu operasi. Harus hanya satu operasi yang melakukan perubahan ini. Sehingga jika ada operasi lain yang akan merubah maka harus menunggu sampai transaksi yang berlangsung selesai.
Misal ada 2 transaksi transfer antara rek A, dan rek B yang terjadi secara bersamaan:
T1 : Transfer A->B senilai 500
• Kurangi saldo A 500
• Tambah saldo B 500
T2 : Transfer B->A senilai 1000
• Kurangi saldo B 1000
• Tambah saldo A 1000
Nah bayangkan jika transaksi tersebut terjadi secara bersamaan dan di proses tanpa isolasi sehingga akan menjadi:
• Kurangi saldo A 500
• Tambah saldo B 500
• Kurangi saldo B 1000
• Tambah saldo A 1000
Jika terjadi kegagalan pada T1, maka data akan tidak konsisten sebab pada T2 sudah mengganti menambahkan saldo pada B. Demikian pentingnya isolasi, sehingga data tidak akan bisa di akses secara bersamaan oleh lebih dari satu operasi.
Durability
Kemampuan DBMS untuk menyimpan data transaksi yang terjadi. Sehingga jika terjadi kegagalan, DBMS menjamin bahwa data transaksi yang telah tersimpan tidak akan hilang. Banyak DBMS yang menuliskan log untuk suatu transaksi yang dapat digunakan ketika terjadi error pada hardware maupun software.
Salah satu poin penting dalam database transaction adalah atomic, yaitu beberapa perintah dianggap sebagai satu kesatuan. Kalau satu gagal, yang lain harus dibatalkan.
Ini adalah fundamental dari pemrograman dengan menggunakan database relasional.
Pada kasus apa perlu transaction? Ya pada semua kasus yang perlu atomic. Contohnya : header detail. Sekali insert, 1 header dan beberapa detail. Kalo pada waktu insert detail gagal, ya headernya harus diundo, kalo ngga ada header yang gantung tanpa detail sehingga datanya juga jadi salah.
Sekarang balik saya tanya, aplikasi apa yang gak pake skema header detail? Kecuali aplikasi prakarya tugas sekolah, aplikasi bisnis pasti pake header detail.
Itu masalah atomicity. Kemudian ada masalah isolation. Isolation ini artinya, transaction yang belum dicommit, tidak akan bisa dibaca oleh session lain. Contohnya gini, kita terima order 1000 item. Tentunya butuh waktu untuk menginsert 1000 record, misalnya butuh waktu 2 detik. Di dunia prosesor, 2 detik itu lama sekali, dan banyak hal bisa terjadi dalam rentang waktu tersebut. Nah, akan terjadi musibah, kalo kita ternyata ada fitur untuk menghitung jumlah order, katakan saja querynya seperti ini.
select sum(nilai) from t_order where tanggal = '2011-02-02'
yang berjalan di tengah-tengah proses insert tadi, misalnya pada waktu baru terinsert 53 order saja. Query hitung ini dijalankan oleh user lain. Suatu hal yang sangat umum terjadi, aplikasi diakses beberapa user berbarengan.
Query ini akan menghasilkan nilai yang salah, karena 1000 order itu belum tentu sukses diinsert. Misalnya pada record ke 143 terjadi mati lampu, hardisk penuh, komputer hang, browser ketutup, laptop kesiram kopi, usernya menekan tombol cancel, validasi stok produk tidak cukup, atau whatever kejadian remeh-temeh yang umum terjadi dalam kehidupan sehari-hari, tentu akan terjadi kekacauan. Karena tidak atomic, maka kita tidak tau sudah berapa record yang terinsert, sehingga menyulitkan proses recovery. Order mana yang harus diinsert ulang, dan order mana yang sudah masuk? Karena tidak ada isolation, maka user yang menjalankan perhitungan order akan mendapat hasil yang tidak sahih kebenarannya.
Seandainya saja kita menggunakan transaction dengan benar, maka pada waktu terjadi sesuatu pada waktu proses insert tadi, maka posisi database akan dikembalikan ke posisi sebelum insert dilakukan. Karena posisi sebelum insert kita tahu dengan pasti, maka recovery gampang. Insert ulang saja 1000 order tadi tanpa kecuali. Sederhana dan mudah.
Jadi kalo ada di sini yang bilang bikin aplikasi bisnis tanpa transaction, maka itu adalah nonsense. Tidak peduli kalo sampe saat ini jalan lancar, maka itu hanyalah kebetulan belaka, dan kita tidak mau selamanya mengandalkan keberuntungan kan? Kalau sampai saat ini berjalan lancar, ya mungkin aplikasinya cuma dipakai 1 concurrent user saja dan itupun jarang-jarang pake.
Nah, jadi transaction itu adalah fitur fundamental yang harus digunakan, sama seperti kalo kita keluar rumah ya harus pake celana. Di daerah lain sana orang kemana2 cuma pake koteka, dan saya tidak mau berdebat dengan mereka urusan celana. Jadi kalo masih ada yang bersikukuh bikin aplikasi bisnis gak pake transaction, ya silahkan, saya tidak mau berdebat urusan ini. Percuma berdebat sama orang yang gak pake celana ;p
Selanjutnya, sebetulnya apa benar transaction itu memberatkan aplikasi? Hmm … ini sebetulnya hanyalah mitos belaka. Yang mau mendebat silahkan sajikan benchmark antara non-transactional dan transactional. Kalo selisih performance cuma 100%, artinya kalo non-transactional cuma 2 kali lebih lemot, saya mendingan upgrade hardware daripada mengorbankan data integrity untuk gain performance yang tidak seberapa ini.
Jadi, apa kita tidak boleh pakai MyISAM ? Tentu ada waktu dan tempatnya. Data2 read only seperti misalnya tabel kategori, master produk, bolehlah pake MyISAM. Tapi kalo sudah data header detail, ya harus InnoDB dan harus menggunakan transaction supaya atomic.
Setelah kita menggunakan InnoDB, sebetulnya kita tidak bisa non-transactional. Kalo kita tidak begin dan commit secara explisit, sebenarnya untuk tiap SQL statement, itu dianggap satu transaction. Sehingga SQL seperti ini :
update table harga set nilai = nilai + 1000;
Sebetulnya akan dijalankan seperti ini ;
begin;
update table harga set nilai = nilai + 1000;
commit;
Ini namanya fitur autocommit. Di MySQL defaultnya dienable.
Dengan adanya autocommit ini, justru kita akan lebih lemot kalo tidak menggunakan transaction secara benar. Contoh, insert 100 data produk. Kalo tanpa begin dan commit explisit, berarti ada 100 begin dan ada 100 commit, artinya 100 kali menjalankan transaction. Akan lebih efisien kalo kita lakukan explisit, seperti ini :
begin;
insert into table produk (kode) values ('P-001');
... ulangi 99 kali lagi ..
commit;
Cara di atas hanya akan membutuhkan satu transaction saja. Jauh lebih efisien.
Baiklah, ada beberapa pesan moral di artikel ini
1. Header detail harus dioperasikan secara atomic
2. Operasi yang belum selesai, tidak boleh dilihat session lain, sehingga untuk aplikasi multiuser, pasti butuh isolation
3. Karena aplikasi bisnis umumnya multiuser, dan pasti punya skema header-detail, maka pasti harusmenggunakan transaction
4. Masalah performance di transaction umumnya mitos belaka, dan walaupun ada, tidak sebanding dengan mengabaikan integritas data
5. Jangan lupa pakai celana kalau keluar rumah
Pembaca setia blog saya tentu paham bahwa biasanya saya memberikan anjuran dengan kata-kata sebaiknya, tergantung situasi, dan istilah-istilah yang relatif. Tapi di artikel ini, banyak kata-kata pasti, harus, dan sejenisnya. Ini karena masalah transaction ini berkaitan dengan integritas data. Aplikasi yang kita buat haruslah bisa dipercaya untuk menghasilkan perhitungan yang benar. Tanpa menjaga integritas data dengan transaction, mustahil perhitungan yang benar bisa didapatkan.
Langganan:
Postingan (Atom)