RM> ya... bantuin optimizernya lah... dengan begini akses plannya udah
RM> kita optimasi duluan sebelum, optimizer jalan.
Untuk kebanyakan kasus harusnya optmizer yg membantu kita, bukan
sebaliknya. Plan yg terbaik menurut saya yaitu tanpa plan.
RM> menurut saya sub-query itu sangat memudahkan masalah, selain
RM> optimasi akses plan yang bisa kita atur, query-nya jadi lebih
RM> modular...
Tanpa anda buat sub-query optimizer pasti sudah menyeleksi record2 yg
akan dijoin. Ketika MySQL belum mendukung sub-query, di manualnya
bilang bahwa kebanyakan sub-query bisa disubtitusikan dgn join biasa.
Firebird juga mendukung sub-query, meski tidak lengkap.
Sebenarnya lebih umum mana antara query A dan B ? Versi yg anda bilang
'unoptimized query' itu tinggal ditambah index seperlunya akan berubah
menjadi optimized. Query model A itu sangat tipikal dan makanan empuk
buat optimizer. Kalo saya lebih memilih query A karena lebih sederhana
dan tidak membuat pusing optimizer (terbalik dgn sangkaan anda).
RM> yang pernah bikin query yang panjangnya mirip sama cerpen.. pasti
RM> perlu subquery... iya nggak??
Versi lain sub-query itu temporary table di MySQL. Sub-query malah
jatuhnya membuat rumit query, bahkan mungkin tidak didukung,
pertahankan dulu versi asalnya. Biarkan optimizer mencari yg terbaik.
Tertanda,
Oguds [36856104]
Berlangganan: [EMAIL PROTECTED]
Stop Berlangganan: [EMAIL PROTECTED]
Keluhan Milis(Unbouncing,spam,dll): [EMAIL PROTECTED]
| Yahoo! Groups Sponsor | |
|
|
Yahoo! Groups Links
- To visit your group on the web, go to:
http://groups.yahoo.com/group/Delphindo/
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
