2009/2/3 Chandra. <chandra.haria...@yahoo.co.id>:
>
> Misalkan tabelnya seperti ini :
> Tabel Barang (IDBarang, Nama, Harga, Jumlah, IDKategori)
> Tabel Kategori (IDKategori, Nama)
> -> baik di Tabel Barang, maupun di Tabel Kategori ada kolom Nama, apakah hal
> ini dimungkinkan dengan HQL?


Bisa saja ... no problem.

>
> Kalo "From Barang A, Kategori B Where A.IDKategori=B.IDKategori" = Select *
> yach?
> (dimna yg ditampilin semua Kolom baik yang ada di Tabel Barang ataupun semua
> yang ada di Tabel Kategori)
> katakan Kalo datanya ada jutaan di tabel barang
> Jika saya mo tampilin kolom2 tertentunya saja di HQLnya gimna yach?
> (dari Tabel Barang = IDBarang, Nama, dari Tabel Kategori Nama)
> (jika select * (yg = "From Barang A, Kategori B Where
> A.IDKategori=B.IDKategori")

select b.id, b.nama, k.nama
from Barang b join fetch b.kategori k

Nanti hasilnya List<Object[]>

> maka proses tersebut akan memakan waktu yg cukup lama gak yach?)
>

Masalah lama atau tidak, itu harus diukur (profiling), gak bisa
tebak-tebakan aja.
Se-expert apapun, sering salah kalau main tebak-tebakan masalah performance.


> Katakan saya biasa menggunakan native SQL :
> Select A.IDBarang, A.Nama, B.Nama as NamaKategori
>
> From Barang A, Kategori B
> Where A.IDKategori=B.IDKategori


Ini pasti biasa pakai MySQL ya ??
Kelihatan dari teknik joinnya yang pakai = di dalam where.
Jaman dulu MySQL belum support sintaks join, sehingga harus begitu caranya.
Tapi sekarang sudah support kok, jadi pakailah sintaks join yang benar.

select A.id, A.nama, B.nama as NamaKategori
from Barang A inner join Kategori B on A.IDKategori = B.IDKategori
where A.nama like '%sabun%';

>
> bagaimana HQLnya yach?..

Itu sudah ada di atas

> kalo untuk inisial (as) nya gimna yach di HQLnya..

Untuk object, langsung saja Barang b, gitu

> saya menggunakan "B.Nama as NamaKategori" untuk membedakan antara kolom Nama
> yg ada di Tabel Barang, dan juga kolom Nama yg ada di tabel kategori..

Result dari query select di HQL akan menghasilkan List<Object[]>
Jadi kalo mau looping menampilkan nama kategori misalnya,

List<Object[]> hasil = session.createQuery("query HQL di atas").list();
for(Object[] o : hasil) {
  System.out.println("ID Barang : "+o[0]);
  System.out.println("Nama Barang : "+o[1]);
  System.out.println("Nama Kategori : "+o[2]);
}

>
> oh ya klo CRUD dengan HQL apakah performance query (kecepatan prosesnya)
> akan lebih cepat dari pada native SQL?.

Sudahlah ... gak usah mikir dulu urusan performance.
Coding dulu aja aplikasinya sampai semua functionality bisa diimplementasikan.
Abis itu kasi ke user suruh test.
Kalau user gak komplain lemot, selesai urusan.
Kalau user bilang lemot, upgrade PCnya.
Kalo masih lemot juga, baru tuning performance.

Harga hardware komputer jauh lebih murah daripada harga manhour programmer.

Premature optimization is the root of all evil.

> (saya beranggapan seperti itu karena HQL "dilakukan" diatas Connection
> Pooling.)
>

Nah kan saya bilang apa ... pasti kalo terlalu banyak asumsi,
anggapan, dan tebak2an jadi salah.
HQL dan Connection Pooling tidak ada hubungannya.
HQL bisa dilakukan tanpa connection pooling, bahkan settingan
defaultnya Hibernate tidak pakai pooling.
Native SQL bisa dilakukan dengan connection pooling.

HQL itu kan teknik query, sedangkan connection pooling itu teknik
koneksi database.

Connection Pooling tidak menurunkan performance, bahkan meningkatkan
performance.
Tanpa connection pooling, kalau kita execute query 2 kali, kejadiannya
seperti ini :
-- query pertama
1. Connect ke dbserver
2. Authenticate (user/password database)
3. Kirim query
4. Terima result
5. Logoff
6. Disconnect
-- query kedua
7. Connect ke dbserver
8. Authenticate (user/password database)
9. Kirim query
10. Terima result
11. Logoff
12. Disconnect

Dengan Connection Pooling :
-- query pertama
1. Connect ke dbserver
2. Authenticate (user/password database)
3. Kirim query
4. Terima result
-- query kedua
5. Kirim query
6. Terima result
7. Logoff
8. Disconnect

Sedangkan selama aplikasi nyala, query kan gak cuma 2 kali, tapi bisa
jutaan kali.

So ... next time jangan terlalu banyak berasumsi ya.



-- 
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --

Kirim email ke