Selasa, 05 Juli 2011

Re: [belajar-access] Revisi Hasil eksperimen

 

Dear All,

Saya perjelas kembali untuk kasus yang 28 user, bahwa seluruh user berfungsi
sebagai kasir (mungkin mirip posisi kasir pada program POS gitu lah)
sehingga sifat daripada manipulasi datanya adalah penambahan data
(appending).

Biasanya pada database yang bikin lambat adalah pengambilan data (seperti
pada query select).

Yang saya lakukan secara standar adalah:
1. Primary key sealu saya gunakan tipe data NUMERIK
2. Selalu ada Primary Key pada setiap tabel. Hal ini juga merupakan
persiapan kalau2 databasenya sampai perlu export ke SQL Server, saya nggak
perlu repot2 ngerubah field2 tabelnya
3. Untuk tabel yang recordnya banyak dan kapasitas nya besar saya gunakan
dummy tabel sebagai perantara, dan saya hindari query yang kompleks atau
yang bertingkat.
4. Pengambilan data dari BE hanya dilakukan pada tabel2 yang berkaitan
dengan TRANSAKSI saja (misal: tabel_penjualan, tabel_pembelian, stok_barang,
dll)
Untuk tabel2 non transaksi saya letakkan di FE masing2 (misal:
tabel_master_barang, tabel_data_karyawan, dll)
5. Sedapat mungkin saya hindari query yang memilih semua data (misal: select
* from tabel_penjualan)
6. Perintah2 domain aggregate yang sangat menurunkan kecepatan saya hindari
(DLookUp, Dmin, Dmax, dll)
7. Indexing yang tepat. Index sampe kebanyakan juga bisa bikin lambat,
gunakan seperlunya pada field2 inti yang berkaitan dengan proses searching
aja)

Mungkin untuk kasus2 di atas Sdr Tio Adjie sudah merasakan perbedaannya
(antara sebelum dan sesudah dioptimalkan), dan dikantor Sdr Tio, MDB Access
juga digunakan oleh lebih dari 5 user kok.
(mana nih mas Tio . . kok diem2 aja, ikutan share doong ha ha ha . . )

Semoga share ini bisa menjawab pertanyaanya, para master di milis ini
silahkan koreksi atau tambahkan bila ada salah dan kurang.

Untuk mas Yudi Hantoro, pertanyaan anda via Japri saya harap sudah terjawab
dengan jawaban diatas yaa, saya jawab disini sekalian agar bisa digunakan
sebagai bahan diskusi

Mohon maaf topiknya malah jadi melenceng dari Subjectnya nih, mungkin kalau
mau dibahas lebih lanjut harus diganti subjectnya (misal: optimalisasi
database, atau apa gitu lah ha ha ha . .:)) )

Regards,

Nino G
(www.AstroDigi.com)

----- Original Message -----
From: "Hendra Agestha Hamid" <the_agestha@yahoo.com>
To: <belajar-access@yahoogroups.com>
Sent: Wednesday, July 06, 2011 9:59 AM
Subject: Re: [belajar-access] Revisi Hasil eksperimen

Maaf Heru kmrn saya coba mau jawab cuma karena newbie jadi gak pede...
Daripada saya nerangin salah berikut saya coba copas dari Help Access, saya
pikir cukup jelas., tambahan lagi untuk field yang foreign key
pada relationships harus di index Yes/Duplicate OK., selebihnya para pakar
mungkin lebih punya pengalaman nyata.

An index helps Microsoft Access find and sort records faster. Access uses
indexes in a table as you use an index in a book: to find data, it looks up
the
location of the data in the index. You can create indexes based on a single
field or on multiple fields. Multiple-field indexes enable you to
distinguish
between records in which the first field may have the same value.
Deciding which fields to index
You'll probably want to index fields you search frequently, fields you sort,
or
fields that you join to fields in other tables in queries. However, indexes
can slow down some action queries such as append queries, when the indexes
for
many fields need to be updated while performing these operations.
The primary key of a table is automatically indexed, and you can't index a
field whose data type is OLE Object. For other fields, you should consider
indexing a field if all the following apply:
* The field's data type is Text, Number, Currency, or Date/Time.
* You anticipate searching for values stored in the field.
* You anticipate sorting values in the field.
* You anticipate storing many different values in the field. If many of the
values in the field are the same, the index may not significantly speed up
queries.

Multiple-field indexes
If you think you'll often search or sort by two or more fields at a time,
you
can create an index for that combination of fields. For example, if you
often
set criteria for LastName and FirstName fields in the same query, it makes
sense
to create a multiple-field index on both fields.
When you sort a table by a multiple-field index, Microsoft Access sorts
first
by the first field defined for the index. If there are records with
duplicate
values in the first field, Microsoft Access sorts next by the second field
defined for the index, and so on.
You can include up to 10 fields in a multiple-field index.

________________________________
From: Heru Wibowo <heru.wibowo4456@gmail.com>
To: belajar-access@yahoogroups.com
Sent: Wed, July 6, 2011 8:06:17 AM
Subject: Re: [belajar-access] Revisi Hasil eksperimen

Waduh....topik ini sudah ditutup yah.....koq ndak ada yang nanggepin sama
sekali
yah? atau mungkin baru pada eksperiment untuk diatas 28 user ?

2011/7/5 Heru Wibowo <heru.wibowo4456@gmail.com>

men-cuplik ...hehee...istilah aja bang Nino....pada salah satu paragraf :
>
>Keempat:
>Hal lain yang menentukan kecepatan adalah: tingkat optimalisasi kita
sebagai
>developer dalam mengoptimalkan proses normalisasi database. Rendudancy data
>yang rendah dan indexing yang tepat akan sangat berpengaruh pada
peningkatan
>kecepatan proses.
>
>bla..bla..bla....
>
>terus terang sangat kagum, 28 user tapi speed masih bagus....kalau bang
Nino
>berkenan....mohon bocoran ilmunya ( saya pake 5 user aja udah lemot)
>salah satunya : bentuk normalisasi yang seperti diatas itu gambaranne kayak
apa
>yah ?
>maksud saya dari jenis-jenis field pada suatu tabel, hal apa aja yang
kira -
>kira perlu dilakukan indexing, dan yang tabu dilakukan ?
>
>Demikian, atas masukan dari bang Nino diucapkan terima kasih.
>
>Salam,
>HerDja
>
>
>
>2011/7/5 Nino Guevara Ruwano <nino@astrodigi.com>
>
>
>>
>>Link Table mas, dipakai di program penjualan, ke 28 user adalah
>>kasir/penerima order yang aktif menginput data pembelian.
>>
>>Rgds,
>>
>>Nino
>>
>>----- Original Message -----
>>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com>
>>To: <belajar-access@yahoogroups.com>
>>
>>Sent: Monday, July 04, 2011 12:27 PM
>>Subject: RE: [belajar-access] Revisi Hasil eksperimen
>>
>>Wah memang beruntung bergabung dengan Milis...nambah terus euy ilmunya
>>dari
>>Share rekan2.
>>
>>Menarik sekali dengan pengalaman Mas Nino yg menemukan BE Access tdk turun
>>performnya bila dipakai di Jaringan+Multi User,
>>28 user lagi, hal ini tentu berbeda dari "teori" yg saya baca (lha belum
>>pernah
>>nyoba sendiri....) dan juga berbeda dengan pengalaman
>>dari Mas Heru Wibowo ...Halo mas Heru) yg disampaikan di e mail sebelum
>>ini...duh tambah pusing hasil pengalaman beda2 nih.. hahaha...
>>Btw itu yg 28 user koneksinya pakai apa mas..? Link Table atau connection
>>string..?
>>
>>Regards
>>Hendra
>>
>>________________________________
>>From: Nino Guevara Ruwano <nino@astrodigi.com>
>>To: belajar-access@yahoogroups.com
>>Sent: Mon, July 4, 2011 9:10:53 AM
>>Subject: Re: [belajar-access] Revisi Hasil eksperimen
>>
>>Dear Mas Hendra,
>>
>>Terima kasih atas informasinya, sebagai catatan tambahan dari pengalaman
>>saya dalam implementasi.
>>
>>Pertama:
>>BE MS Access nggak drop karena dipakai oleh lebih dari 1 user kok, saya
>>sudah implementasikan dalam jaringan yang dipakai oleh 28 user sekaligus
>>yang semuanya berfungsi sebagai kasir penerima order, hasilnya tetep bisa
>>jalan secepat kilat.
>>
>>Kedua:
>>BE MS Access baru menurun kecepatannya pada record yang sudah puluhan
ribu.
>>Ini terjadi pada program parkir yang sudah saya implementasikan di sebuah
>>mall di Bogor. Dalam sehari transaksi bisa mencapai ribuan, sehingga
ratusan
>>ribu transaksi bisa tercapai hanya dalam 3 atau 4 bulan saja.
>>
>>Bisa diatasi dengan membuat program yang menutup transaksi setiap bulannya
>>dan memindahkan transaksi bulan lalu kedalam database baru yang dijadikan
>>backup.
>>
>>Pada client lain yang transaksinya besar, saya pindahkan datanya ke SQL
>>Server. Hasilnya seperti yang saya sudah sampaikan pada email sebelumnya,
>>kecepatan load data sedikit menurun (hanya saat awal buka form) tapi
stabil
>>dan tidak perlu compact & repair.
>>
>>Ketiga:
>>Compact & Repair. Ini adalah masalah yang jadi krusial dan menurut saya
ini
>>jadi salah satu kelemahan BE MS Access. Karena pada BE yang sudah
berukuran
>>>300MB dalam puluhan kali compact & repair selalu saja ada satu saat
dimana
>>data rusak, entah tidak bisa dibuka atau sebagian data hilang.
>>
>>Harap masalah ini jadi pertimbangan penting bagi rekan2 yang membangun
>>system dengan jumlah record besar dan kapasitas besar.
>>
>>Mungkin harus dibuat experimen tersendiri untuk mencari penyebab utama dan
>>juga solusi tepatnya. Saat ini saya belum punya cukup waktu untuk
>>berexperiman disini :)
>>
>>Keempat:
>>Hal lain yang menentukan kecepatan adalah: tingkat optimalisasi kita
sebagai
>>developer dalam mengoptimalkan proses normalisasi database. Rendudancy
data
>>yang rendah dan indexing yang tepat akan sangat berpengaruh pada
peningkatan
>>kecepatan proses.
>>
>>Pada sebuah kasus pada client di Tangerang yang sempat saya tangani dengan
>>engkong access (mas Lusky) kita sempat temukan FE yang dibangun dengan
>>Delphi yang konon adalah system aplikasi tercepat , ternyata kecepatannya
>>sangat jauuuuuuuuh tertinggal dengan aplikasi yang dibangun dengan MS
>>Access, penyebabnya ya itu tadi . . normalisasi yang nggak optimal mas .
>>.Delphi nggak optimal VS MS Access yang optimal, ya jelas jadi cepetan MS
>>Accessnya :)
>>
>>OK mas Hendra, demikian review dan sharing dari saya semoga berguna untuk
>>anda dan juga warga milis yang lain. Terus berkarya, dan semoga sukses . .
.
>>
>>Regards,
>>
>>Nino
>>(www.AstroDigi.com)
>>
>>----- Original Message -----
>>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com>
>>To: <belajar-access@yahoogroups.com>
>>Sent: Sunday, July 03, 2011 9:00 AM
>>Subject: Re: [belajar-access] Revisi Hasil eksperimen
>>
>>Dear Mas Nino,...
>>Terima kasih Mas Nino, itu bisa saya lakukan karena gak bisa bikin
>>aplikasinya
>>... (..), saya betul2 newbie mas...mgkn karena belum pernah pakai
>>makanya sebelum pakai saya cek and ricek dulu,....
>>Dibawah ini saya copas hasil browsing saya terhadap perbandingan2 antar
BE,
>>ada
>>yg comment itu dari MVP SQL Server juga.
>>Dari semua itu akhirnya saya berkesimpulan akhir : Pakailah BE Access Link
>>Table
>>method (utk FE Access) bila itu untuk single user dan tdk
>>di local station tdk di jaringan, dijamin lebih cepat dan saya sudah
>>buktikan
>>sendiri.
>>
>>Sebab utamanya kenapa jangan dipakai pada jaringan dan multi user adalah
Jet
>>Access pada BE drop bila dipakai lebih dari 1 user (saya gak bisa buktikan
>>langsung tapi saya percaya banget soalnya yg ngomong para MVP ).
>>Tapi kemudian satu lagi saya langsung sadar setelah saya baca pengalaman
mas
>>Nino,...dan ini mungkin juga jadi pertimbangan penting yaitu BE Access
>>harus sering2 di Compact n Repair,,,(setau saya MYSQL dan SQL Server tdk
>>perlu
>>ini) ...terima kasih Mas Nino,,,pengalaman Mas bener2 berguna sebagai
>>pertimbangan lainnya.
>>
>>Regards
>>Hendra
>>
>>Berikut saya copas hasil browsing saya :
>>
>>I think Albert Kallal's comment is right, and the fact is that if you have
>>a
>>single-user app running on a single workstation (Access client with SQL
>>Server
>>running on the same workstation as a client), it will quite often be
slower
>>than if the setup on that workstation were Access client to Jet/ACE back
>>end on
>>the same machine. SQL Server adds a lot of overhead that delivers no
>>benefit
>>when there is no network in between the client and the SQL Server.
>>The performance equation flips when there's a network involved, even for a
>>single-user app. If the Access client runs on a workstation, and the SQL
>>Server
>>on a server on the other end of a network connection (even a fast one), it
>>will
>>likely be faster than if the data is stored in a Jet/ACE file on a file
>>server.
>>
>>But it's not a given, in my opinion. It depends entirely on the
engineering
>>of
>>the application and the excellence of the schema.
>>
>>Lainnya :
>>Performance questions are very difficult to
>>answer up front, because there are so many "it depends". What I can
>>say, is that if you do this in Access, you should do it in a local
>>Jet database, not not a linked SQL Server table.
>>
>>If you ask me to place my bets, I put them on Access for this one.
>>String processing is not SQL Server's best game.
>>
>>________________________________
>>From: Nino Guevara Ruwano <nino@astrodigi.com>
>>To: belajar-access@yahoogroups.com
>>Sent: Sun, July 3, 2011 7:56:32 AM
>>Subject: Re: [belajar-access] Revisi Hasil eksperimen
>>
>>Dear Mas Hendra,
>>
>>Sebelumnya saya ucapkan terimakasih atas usaha anda dalam melakukan
>>experimen perbandingan data dengan BE berlainan tersebut. Salut! dan
sangat
>>membantu warga milis dalam membangun database system dikemudian hari.
>>
>>Sedikit urun pengalaman, saya pernah menggunakan BE MS Access yang
kemudian
>>terpaksa saya pindahkan ke SQL Server karena setelah record mencapai
puluhan
>>ribu (saat itu sudah 38ribu lebih) pengambilan data ke BE MS Access
menjadi
>>lambat, baru agak cepat kembali bila kita melakukan compact and repair
pada
>>BE
>>
>>Dalam sehari user harus melakukan compact and repair yang memakan waktu
>>sekitar 5 menitan agar kecepatan tetap bagus, akhirnya saya pindahkan
semua
>>data ke SQL Server dan hasilnya memang SQL server butuh waktu 2 detik
lebih
>>lama untuk menampilkan data tapi stabil, dan user tidak direpotkan dengan
>>compact and repair berulang2
>>
>>Bahaya yang timbul dari proses compact and repair adalah kerusakan data,
>>entah kenapa sampai dengan MS Access 2010 lahir dalam puluhan kali compact
>>and repair pasti ada aja sekali waktu dimana database rusak, meskipun saya
>>selalu melakukan backup tetapi masalah seperti ini cukup merisaukan.
>>
>>Coba mas Hendra uji lagi BE anda dengan beban record 30ribuan mas, mungkin
>>hasilnya bisa berbeda. Untuk BE MySQL saya belum pernah coba dengan FE MS
>>Access, biasanya saya gunakan PHP untuk FEnya.
>>
>>Sekali lagi salut buat mas Hendra yang bersedia meluangkan waktunya untuk
>>experimen ini, keep going mas . . sukses ya
>>
>>Regards,
>>Nino
>>
>>----- Original Message -----
>>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com>
>>To: <belajar-access@yahoogroups.com>
>>Sent: Saturday, July 02, 2011 11:02 AM
>>Subject: [belajar-access] Revisi Hasil eksperimen
>>
>>> Dear warga Milis,...
>>>
>>> Mohon maaf, setelah saya ulang2 lagi seluruh hasil eksperimen saya,
>>ternyata
>>> untuk membuka Form Source LT to MySQL mau
>>> terbuka alias tidak hang, cuma butuh waktu agak lama, kemudian move last
>>juga
>>> cukup sebentar (move last sekitar 5 detik)
>>> Yang LT to SQL server buka Form cepat tapi move last lama sekali
(sekitar
>>1
>>> menit).
>>> Tapi tetap dibanding keduanya di atas masih lebih cepat yang Source LT
to
>>Mdb,
>>> baik buka Form maupun move lastnya.
>>>
>>> Regards
>>> Hendra
>>>
>>
>>
>
>
>--
>HerDja
>
>

--
HerDja

__._,_.___
Recent Activity:
SPAM IS PROHIBITED
.

__,_._,___

Tidak ada komentar:

Posting Komentar