wah load data lebih dua juta cuma 5 detik ? yang bener ? berapa join bos ? ----- Original Message ----- From: Bace - Bace To: [email protected] Sent: Friday, April 20, 2007 2:06 PM Subject: [Programmer-VB] Re: Masalah Tuning2an
Select * from Tebel 1 where field1 in (select Field 2 from table2 ) itukan perintahnya mengambil data di tabel2 dulu baru mencarinya di tabel1, klu dari query di tabel2 ada 10, maka yang 10 itu dicari di tabel1. Jika tabel data di tabel1 berjumlah jutaan, wah bayangkan waktu yang diperlukan...:) apalagi dicari di komp server...(pusing deh mikirnya...) Lebih cepet pake Select * From table1 inner join table2 on fiels1=field2 sudah tentu lebih cepat, karena data yang dicari tabel1 dahulu baru digabung dengan tabel2. Sebenarnya perintah Select * from Tebel 1 where field1 in (select Field 2 from table2 ) bisa dibuat lebih cepat dengan diberi hasilnya langsung, seperti : Select * from Tebel 1 where field1 in (1,2,4,5) dengan catatan 1,2,3,4,5 adalah hasil pencarian ditabel2 dengan menggunakan : select Field 2 from table2 saya menggunakan metode ini untuk pencarian data pada banyak tabel didalam database. --- In [email protected], "sukisno K" <[EMAIL PROTECTED]> wrote: > > Hem mini asikk nehh kayanya perlu di bahas lebih lanjut dehh :D, > > Pengalaman saya sihh tuning data base masalah indext cara kerja client side > or server side itu penting deh kayanya, terus terang program yang saya buat > yang udah jalan hampir 4 tahun dgn data yang edan :D ( 1 hari 1000 record > untuk header minx dan header punya 5 detail itu baru satu contoh ) jalanya > dari dulu sampe sekarang speednya tetep segitu ( alias kalau di timbang > timbang kalau bisa lebih cepet pasti lebih bagus ) :D. nahh tapi perubahanya > kayanya mendasar dan banyak. Itulah sebabnya pengen denger pendapat temen > temen soal tuning data base. > > Cth ya saya pake mssql dan mysql kalau pake statement query spt ini kenapa > lebih lambat ya ?? apa lagi kalau jumlah recordnya banyak > > > > Select * from Tebel 1 where field1 in (select Field 2 from table2 ) > > > > Lebih cepet pake > > Select * From table1 inner join table2 on fiels1=field2 > > > > Masih banyak kasus aneh lagi deh :D sampe hari ini sih ketemu pemecahanya > tapi tetep aja bingung, aklau teori kan sejubel gakk tahu sapa yang bener > itu juga masalah :D apa undang Microsoft aja ya heuhuehuehue > > > > T'rims > > Sukisno > > > > _____ > > From: [email protected] [mailto:Programmer- [EMAIL PROTECTED] > On Behalf Of Bace - Bace > Sent: Friday, April 20, 2007 9:56 AM > To: [email protected] > Subject: Re: [Programmer-VB] Masalah Tuning2an > > > > Saya rasa masalah tuning2an dalam penggunaan database tidak perlu > dirisaukan. Program vb yang sudah saya buat, dapat mengambil data pembayaran > per costumer dengan cepat (hitungan 5 detik, dilakukan via jaringan) untuk > data pembayaran yang banyaknya di atas 2 juta data. padahal komputer klien > yang dipergunakan hanya pentium 2. > > > > Menurut pengalaman saya, > > Apapun database yang dipergunakan, jika menggunakan ADODC VB perintah yang > digunakan untuk mengambil database cukup perintah select saja, kemudian > untuk menyortir data gunakan kondisi where nya saja. dan lakukan pengolahan > data di komputer klien, bukan diservernya. Untuk menambah gunakan addnew, > menyimpan update. menghapus delete. Dengan begini semua perinta dilakukan di > tabel virtual didalam memori kemudian jika ada perubahan diupdate kedalam > databse diserver. > > > > tabel data sebaiknya di satukan dalam satu tabel, supaya lebih terkoordinir, > jangan dipisah2 pertahun, karena jika dipisa pertahun, pengguna akan > kebingungan jika tabel untuk tahun yang akan dimasukkannya tidak ada. > > > > Untuk baris kode penggunaan ADODC saya rasa sudah standard dari sononya > (pembuatnya) jadi tidak ada yang bisa disederhanakan lagi. Hanya programer > dapat mengakalinya dengan membuka dan menutup koneksi apabila sudah tidak > diperlukan lagi, agar memory komputer dapat dipakai oleh kompu untuk > resource lain. > > > > > Semoga membantu: =(oVo)= > ==================== > BaceInside Publisher > Copyright @2007 > Not for reproduced, republished. > Thank You > ==================== > > > > ----- Original Message ---- > From: Ade Aan Wirama (gmail) <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, April 19, 2007 10:48:21 PM > Subject: Re: [Programmer-VB] Masalah Tuning2an > > Lebih bagus sih dipisah, walaupun saya sendiri selama ini nggak pernah misah > database berdasarkan tahun, soalnya repot buat codingnya :D > > Best Regards, > Ade Aan Wirama > > ----- Original Message ----- > From: "ChipMunks" <[EMAIL PROTECTED] co.id > <mailto:chipmunks%40prasidha.co.id> > > To: "Ade Aan Wirama (gmail)" <Programmer-VB@ > <mailto:Programmer-VB%40yahoogroups.com> yahoogroups. com> > Sent: Wednesday, April 18, 2007 11:41 AM > Subject: [Programmer- VB] Masalah Tuning2an > > > Ade > > Ade> Spek tinggi tidak berarti bahwa kita tidak memerlukan tuning baik > dari sisi > > Ade> code dan database. Dan setinggi-tingginya spek kalo code dan > databasenya > > Ade> berantakan akan lambat juga. > > > > Ade> Mulai dari sekarang untuk tuning dan merapikan baris kode dan > database, > > Ade> manfaatnya akan terasa hingga tua :D > > > > Ade> Best Regards, > > Ade> Ade Aan Wirama > > > > menyambung yang mas ade bilang, untuk transaksi tahunan lebih baik > > mana database itu dibuat pertahun atau seluruh tahun dijadikan 1 > > database.... > > > > mungkin bisa sharing... plus / minus dan menurut kalian bagaimana ? > > > > Salam, > > ChipMunks (Copy Paste Programmer) > > mailto: [EMAIL PROTECTED] <mailto:ChipMunks%40prasidha.co.id> co.id > > Yahoo : Henqy > > Skype : Hengky_Purnomo > > > > > > > > > > _____ > > Ahhh...imagining that irresistible "new car" smell? > Check out new > <http://us.rd.yahoo.com/evt=48245/*http:/autos.yahoo.com/new_cars.html ;_ylc= > X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM- > cars > at Yahoo! Autos. > ------------------------------------------------------------------------------ Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.428 / Virus Database: 268.14.14/547 - Release Date: 11/22/2006 5:41 PM
