Development Application : Data Access layer

[Angga Hantara]

Hi all ,

Saya ingin menanyakan kepada para suhu disini tentang Data Access Layer , dari dulu saya ber prinsip aplikasi harus menerapkan "DB Agnostic" di mana
database dapat di pindah tanpah harus meng configurasi Layer lainnya ,

Sampai kemarin ada seminar di kantor yang menyatakan kebalikannya :
Inti dari seminar tersebut menyatakan untuk menggunakan Stored Procedure dengan maksimal

• Data Acces Layer tidak di perlukan karena terlalu tergantung dengan bahasa , karena data lebih tahan lama dari pada languange itu sendiri
• Karena jika kita menggunakan database untuk melakukan logic , kita hanya perlu menambah/Configurasi server agar proses datanya lebih cepat
• Effort migrate ke database lain jika menggunakan standart SQL kecil daripada menggunakan DAL *ini saya tidak setuju sama sekali
• Easy to maintenance , karena tinggal customize di database
• Company sangat jarang mengganti teknologi database ,
  

Bagaimana pendapat teman-teman sekalian ? kalo saya masih tetap dengan paham DB agnostic :))

[Ifnu bima]

+1 pake DAL :)

2013/6/18 Angga Hantara <angga....@gmail.com>:

> --
> Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT"
> dari Grup Google.
> Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim
> email ke it-project-indonesia+berhenti berlan...@googlegroups.com .
> Untuk mengeposkan pesan ke grup ini, kirim email ke
> it-project...@googlegroups.com.
> Kunjungi grup ini di http://groups.google.com/group/it-project-indonesia.
> Untuk opsi lainnya, kunjungi https://groups.google.com/groups/opt_out.
>
>



--
http://ifnubima.org/indo-java-podcast/
http://project-template.googlecode.com/
@ifnubima

regards

[Irwansyah Irwansyah]

Intinya ada di Dependency Injection dan Abstraction. sol

2013/6/18 Angga Hantara <angga....@gmail.com>

--

[Angga Hantara]

@Irwansyah
Buat seabstrak mungkin untuk bisa di reuse yah :D.
Kalo depency injection saya masih belum bisa maksmalin ini masih tahap belajar

Udah +2 untuk menggunakan DAL nih :D,
ada yang pernah menggunakan cara all logic in SP ?

[Irwansyah Irwansyah]

Logic di SP kelebihan utamanya kalau ada perubahan tinggal rubah SP-nya udah langusng keupdate tidak perlu compile + deploy. Ada juga beberapa kelebihan lain seperti data transfer yang langsung dimemory tanpa harus lewat network namun belum tahu berapa signifikan.

Nah, SQL language yang dipake apa dulu? Namun umumnya untuk reuse hanya sebatas custom function atau call SP yang lain. Tidak bisa create class, etc.

Kekurangannya, code akhirnya bisa jadi very-very long lines dan tidak semua RDBMS support debugging SP.

Saran saya mendingan logic di code terutama di jaman modern seperti ini dimana sudah ada ORM, DI, Repository Pattern. SP sangat old fashioned.

2013/6/18 Angga Hantara <angga....@gmail.com>

[Reza Lesmana]

Kalau memang perusahaannya sudah membeli license db untuk beberapa tahun ke depan + aplikasinya hanya untuk internal perusahaan itu saja ya bener argumentasinya.

Tp klo licensi db-nya cuma 1 atau 2 tahun (yang berarti ada kemungkinan untuk ganti tahun berikutnya , atau emang selalu harus dianggarkan untuk penggantian teknologi database setiap tahunnya misalnya) + aplikasi akan disebar untuk perusahaan lain / anak perusahaan, ya ga berlaku argumentasinya <--- ini yang lebih sering berlaku. :D

2013/6/18 Angga Hantara <angga....@gmail.com>

--

[Endy Muhardin]

Menurut saya, sebenarnya ini inti pertanyaannya bukan masalah DAL. 

Tapi lebih seperti ini, "Mana yang lebih baik, business logic di SP atau di kode program?"

Kalau pilih yang di kode program ya tentu harus pakai DAL, supaya codingnya rapi dan mudah maintenance.

Masa SQL mau ditulis di onClick handler ;)

Nah SP vs Kode Program:

Plusnya SP: 

- datanya gak kemana2, untuk pengolahan data yang besar lebih efisien karena gak ada perpindahan data dari db ke aplikasi dan ke db lagi.

Minusnya SP

- dukungan tools di SP kurang. Kalau di Java/PHP/dsb, kita bisa enable fungsi debug di IDE, bisa output ke console, dan pakai berbagai teknik coding lainnya. Tidak puas dengan Eclipse, ganti Netbeans. Netbeans lemot, pindah ke IntelliJ. Belum lagi dukungan tools lain seperti unit test, logging, dsb.

- dukungan library di SP terbatas. Misalnya, mau hitung 17 hari yang akan datang jatuhnya hari kerja atau libur? Ada berapa hari kerja dari sekarang sampai akhir tahun? Kalau di kode program kita bisa search dan pakai library yang sudah jadi. Di SP kita cuma bisa pakai yang disediakan sama vendornya.

- pilihan strategi lebih banyak. Di kode program, kalo dia lemot kita bisa cari solusi lain, misalnya pakai in-memory cache, distribusi ke banyak thread, pakai teknik messaging, dsb

- sulit dikelola dengan version control. Biasanya programmer SP langsung coding dan ngetes di database. 

Butuh disiplin ekstra untuk memindahkan hasil yang udah beres ke version control.

- Vendor lock-in. Sekali pakai PL/SQL jangan harap bisa ganti database jadi MySQL. Sekali pakai TransactSQL ya forever terikat sama SQL Server.

Nah itu plus minusnya. Agak berat ke minus, soalnya saya sendiri menganut aliran business logic di kode program.

Mungkin rekan2 yang aliran business logic di SP bisa bantu menyeimbangkan. 

Kita diskusi open-minded saja, yang penting tau plus minus. Setelah itu mau pilih mana ya terserah.

Satu lagi, itu seminarnya diadakan vendor DB bukan? 

Kalo iya, tentu mereka punya interest untuk vendor lock-in ;)

Endy Muhardin
http://software.endy.muhardin.com

2013/6/18 Angga Hantara <angga....@gmail.com>

--

[Endy Muhardin]

- Endy Muhardin -
http://software.endy.muhardin.com/about

---------- Forwarded message ----------
From: "Angga Hantara" <angga....@gmail.com>
Date: Jun 18, 2013 6:00 PM
Subject: Re: [Manajemen Proyek IT] Development Application : Data Access layer
To: <endy.m...@gmail.com>
Cc:


@Endy :
kalo seminarnya sih bukan dari vendor DB ,dari Konsultan software gitu .
Iya lebih tepatnya itu sih mas SP vs DAL :D.

Oh iya satu poin lagi yang harus di sebutkan tapi saya masih ragu kebenarannya
Jika menggunakan SP kita mengurangi beban user dalam me load aplikasi kita , karena bebannya sudah di alihkan server .
Sehingga kita bisa mengoptimize untuk berbagai spec pc yang user pakai .

[habibillah]

Aku nimbrung curhat aja...
Di company tempatku semua aplikasi di buat dengan application logic mostly ada di SP. Alasan yang paling sering ditonjolkan adalah performance dan mudahnya maintenance. Untuk alasan performance, mungkin bisa sedikit bisa diterima. Tapi kalau masalah mudah maintenance kayaknya rada-rada menipu.

Ternyata yang dimaksud mudah maintenance itu adalah, seandainya ada bug tinggal di-fix di SP kemudian submit ke DBA dan DBA yang execute di  production. Tapi jika ada bug di applikasi, setelah di fix harus melalui jalur yang panjang mulai dari BA, QA, application owner hingga user. dan ini gak selesai dalam sehari untuk sampai ke production.

Padahal bagiku susah banget maintenance SP yang berisi 1000 baris lebih wkwk.

--
Habibillah
http://habibillah.wordpress.com

[Angga Hantara]

@habibilah

Terus bagaimana konsep itu SP itu diterapkan di perusahan bapak ?
kalo di seminar tempat say itu sih dijelaskan kalo kita hanya perlu menyediakan 1 DBA untuk tester tersebut
jadi tidak perlu repot ke QA sama programmernya .:D

[Endy Muhardin]

2013/6/18 habibillah <habib...@gmail.com>

Ternyata yang dimaksud mudah maintenance itu adalah, seandainya ada bug tinggal di-fix di SP kemudian submit ke DBA dan DBA yang execute di  production. Tapi jika ada bug di applikasi, setelah di fix harus melalui jalur yang panjang mulai dari BA, QA, application owner hingga user. dan ini gak selesai dalam sehari untuk sampai ke production.

Padahal bagiku susah banget maintenance SP yang berisi 1000 baris lebih wkwk.

Biasanya ada alasan yang kuat kenapa suatu kode program itu harus dites sama BA, tester, dst.

Programmer cenderung ngetesnya cuma skenario yang paling simple aja. 

Sedangkan kalo BA, tester, dsb akan mengetes semua skenario baik yang masuk akal maupun yang aneh2.

Kalau argumentasinya dengan SP bisa langsung programmer --> production, 

ya apa bedanya dengan implement di kode program trus programmernya langsung deploy di production.

Malah lebih hemat langkah, gak usah pakai DBA, langsung aja programmernya suruh FTP sendiri ;p

Cuma ya jangan komplain nanti kalo ternyata transaksi 10.000 tapi masuk di jurnal 10.000.000 ;) 

Endy Muhardin
http://software.endy.muhardin.com

[Endy Muhardin]

2013/6/19 Angga Hantara <angga....@gmail.com>

Sebenarnya menurut saya gini. 

Mau implement proses bisnis di SP atau di kode program ya bebas aja.

Masing2 punya plus minus.

Tapi mbok ya jangan ngarang argumen yang aneh2 seperti :

- pake SP gak perlu dites BA

- tidak perlu tester cukup DBA

- dsb

DBA, Tester, BA, Programmer itu punya peran masing-masing. 

Contoh : 

DBA urusannya database. Dia harus tau gimana mempartisi tabel yang besar. 

Harus tau bagusan mana tablespace pakai file atau pakai partisi.

Gimana cara setup replikasi dan master slave.

Berapa alokasi memori untuk table cache dan query cache yang optimal.

Network packetnya mau dibikin berapa KB per segmen.

Kalo query lemot, masalahnya ada di desain tabel, subselect/join, atau index gak bener?

Programmer urusannya coding. Dia harus tau:

- untuk requirement tsb mendingan pakai Java atau PHP

- mau pilih framework yang mana

- lebih tepat mana format data JSON atau XML

BA urusannya proses bisnis. Dia harus tau:

- mau pakai metode depresiasi SL atau DDB (asset-accounting)

- mau pakai perhitungan inventory LIFO atau FIFO (inventory)

- bagaimana menentukan cost center dan profit center (cost-accounting)

- kalau ada pelanggan yang beli barang, trus rusak, boleh dibalikin gak. Gimana perlakuan akunting dan pajaknya

Tester urusannya ngetes aplikasi. Yang dia pikirkan:

- aplikasi ini kalau belum set saldo awal trus insert transaksi, keluar pesan error gak (input validation)

- kalau usernya input ';delete from t_user;select 1;' ketangkap validasi SQL injection gak (security)

- kalau aplikasinya diinstal di Intel Xeon RAM 16GB, berapa maksimum transaksi yang bisa diproses per detik? (stress test)

- pada saat load tinggi, berapa penurunan response time? (performance test)

Nah, kalo ada yang bilang pakai Stored Procedure jadi gak perlu BA dan Tester, cukup DBA aja, saya gak paham dasar pemikirannya ;)

Apakah maksudnya dengan pakai SP trus DBA jadi ngerti akunting dan XSS vulnerability?

Balik lagi ke topik. 

Mending dilihat dari sudut pandang ketersediaan skill aja.

Kalau timnya pengalaman di SP ya go ahead implement di SP.

Kalau timnya kompeten di bahasa pemrograman, ya implement di kode program.

SP bisa dibikin kenceng, kode program juga bisa. Studi kasus udah banyak di google.

Tinggal timnya, bisa gak bikin kenceng baik itu SP maupun kode program?

Endy Muhardin
http://software.endy.muhardin.com

[habibillah]

2013/6/19 Endy Muhardin <endy.m...@gmail.com>

Nah, kalo ada yang bilang pakai Stored Procedure jadi gak perlu BA dan Tester, cukup DBA aja, saya gak paham dasar pemikirannya ;)

Nah aku juga kurang ngerti kenapa kenapa management bug fix-nya seperti itu. Kalau yang di fix cuma SP path ke productionnya bisa lebih pendek :)

Paparan mas Endy di atas aku setuju. berlaku juga di sini, tapi sering juga di bypass :)

--
Habibillah
http://habibillah.wordpress.com

[habibillah]

2013/6/19 Angga Hantara <angga....@gmail.com>

@habibilah

Terus bagaimana konsep itu SP itu diterapkan di perusahan bapak ?

koreksi dulu. ini bukan perusahaan saya :)

kalau konsep aplikasi secara sederhana cuma form dan show data yang didapat dari SP, meski sebenarnya di level aplikasi tetep ada logic juga. cuma kasarnya 70% logic nya simpan di SP.

 

kalo di seminar tempat say itu sih dijelaskan kalo kita hanya perlu menyediakan 1 DBA untuk tester tersebut
jadi tidak perlu repot ke QA sama programmernya .:D

Mungkin management percaya kalau database itu yang punya dan bertanggung jawab adalah DBA, sehangga kalau perubahannya cuma di level SP, ya tinggal submit ke DBA, DBA review, mungkin juga di test, dan kemudian di execute. selesai :)

 

--
Habibillah
http://habibillah.wordpress.com

[edwin bernadus]

ini adalah salah satu perang agama di dunia IT,

logic di stored proc atau di app server ?

beberapa alasan kenapa logic di stored proc:

1. marketing / evangelist yang ngomong pasti orang dari product DB

2. kalau suatu company sudah mature, jalan baik2 saja dengan logic di stored proc,

kenapa harus berubah ?

3. logic di DB pasti lebih stabil,

karena masih satu tier dengan layer data itu sendiri

4. SDM  expert di stored proc, dan sudah malas untuk belajar hal yang baru

saya sendiri tidak suka simpan logic di stored proc karena:

1. ini yang paling penting, 

tidak banyak tool atau library untuk database.

coba diperhatikan tool seperti version control , refactoring , packaging , unit test, ALM.

atau library seperti json, xml, atau library open source lainnya

semua tool dan library itu jauh lebih mature dan lebih banyak di level app server

(java / c# / php / ruby / phython)

2. tidak object oriented, makin susah untuk refactoring.

3. stored proc sulit untuk consume web API.

bayangkan stored proc UserLogin yang harus memanggil fb login API

4. portability, 

saya ambil contoh c# karena pengalaman di sana.

code di c# bisa di porting ke desktop , web , atau segala macam mobile app.

(tapi tetep harus ada penyesusaian dan effort)

kalau logic di stored proc , gimana cara pindahkan ke iOS ?

5. porting stored proc ke database lain

kalau coding stored proc menggunakan ansi c yang standard, porting mungkin tidak terlalu sulit

tapi pada kenyaan nya tidak mungkin pake syntax ansi c doank,

ngapain cape2 beli mahal2 oracle atau sql server tapi ga pake full feature ?

6. trend database noSQL.

ada beberapa case seperti logging yang lebih cocok di noSQL.

jadi trend yang sering berubah itu sekarang  adalah database, bukan app server.

7. cloud hosting

cloud hosting support banyak bahasa. contoh ms azure support nodeJS dan java

kalau di stored proc, itu pasti jauh lebih sulit.

harus sewa VM diinstal db server

kesimpulannya,

kalau start awal, lebih baik tiga tier , pasang logic di app server.

tapi kalau sudah cocok dan baik2 saja logic di sp, kenapa harus berubah ?

thx,

Edwin

2013/6/19 habibillah <habib...@gmail.com>

--