Mengingat db_select jauh lebih lambat daripada db_query, mengapa saya ingin menggunakannya?

69

Untuk latar belakang tentang ini, silakan lihat http://drupal.org/node/1067802 .

Mengingat semua itu, situasi apa yang ada di mana saya mungkin ingin menggunakan db_select (), atau haruskah saya hanya mengandalkan db_query?

7 performance database

— Chris Cohen
sumber

88

Ada 5 alasan untuk menggunakan SelectQuery

Anda sedang membangun kueri dinamis dengan beragam kondisi, gabungan, bidang, dan sebagainya. Lihat field_read_fields () untuk contoh.
Anda ingin menggunakan yang disebut Extender . Extender contoh adalah PagerDefault (menggantikan pager_query () ) dan TableSort (menggantikan tablesort_sql () ). Ini memungkinkan untuk menambahkan fungsionalitas tambahan ke SelectQuery. Lihat juga Bagaimana Anda membuat tabel diurutkan dengan pager dengan data dari tabel kustom? . Contoh: node_page_default () .
Anda ingin mengizinkan modul lain untuk mengubah kueri Anda. Kemudian Anda dapat menambahkan tag yang disebut dan SelectQuery akan secara otomatis memanggil pengait alter yang sesuai untuk tag itu. Saya sangat mengandalkan ini dengan modul Privatemsg saya (Kami sudah melakukannya di D6 dengan pembuat kueri khusus).
Jika Anda ingin / perlu menggunakan sistem node_access untuk hanya menampilkan node, pengguna diizinkan untuk melihatnya. Cukup tambahkan tag 'node_access' ke $ query Anda. Ini menggantikan db_rewrite_sql ().
SelectQuery memiliki beberapa fitur yang membantu membuat kode Anda berfungsi sama di semua basis data yang didukung. Misalnya ada SelectQuery :: orderRandom () . Dan jika Anda memiliki kondisi LIKE, -> condition ('field', $ value, 'LIKE') akan memastikan bahwa itu selalu merupakan perbandingan kasus yang tidak sensitif. Di D6, Anda harus menggunakan RENDAH () untuk apa yang jauh lebih lambat. Tapi AFAIK, tidak ada lebih dari dua ini sekarang.

Jika tidak ada alasan ini berlaku untuk kasus tertentu, gunakan db_query ().

— Berdir
sumber

1

Menambahkan poin kelima, fitur portabilitas basis data seperti orderRandom () dan LIKE case insensitive.

— Berdir

6

Sebagai alasan keenam, saya akan menambahkan kompatibilitas lintas basis data. Oracle queries, misalnya, memiliki sintaks yang berbeda dalam beberapa hal dari MySQL, Postgres dll. Jauh lebih mudah untuk menulis kode untuk menghasilkan sintaks yang benar dari db_select () daripada ketika kode kueri yang tidak terlalu oracle kompatibel. dibuang langsung ke db_query ().

— BrianV

9

The dokumentasi tentangdb_query() mengatakan:

Gunakan fungsi ini untuk kueri SELECT jika itu hanya string kueri sederhana. Jika pemanggil atau modul lain perlu mengubah kueri, gunakan db_select () sebagai gantinya.

— marcvangend
sumber

Terima kasih, tapi itu tidak spesifik. Itu meninggalkan definisi 'string kueri sederhana' cukup terbuka untuk interpretasi. Jika saya memilih di 4 tabel dengan 6 bergabung, apakah itu masih permintaan sederhana, atau haruskah itu dilakukan dengan db_select ()?

— Chris Cohen

3

Ini bukan tentang "permintaan sederhana" tetapi, tentang " string permintaan sederhana " dan sederhana sebenarnya berarti hardcoded dan tidak dinamis. Lihat jawaban saya untuk lebih jelasnya :)

— Berdir

9

Saya selalu menggunakan db_select karena saya lebih suka keterbacaan, pemeliharaan dan kompatibilitas lintas basis data dibandingkan keuntungan kinerja kecil. Selain itu, saya pikir angka-angka yang diberikan dalam masalah tersebut memberikan citra yang salah dari keseluruhan kinerja. Kita berbicara perbedaan 300 mikrodetik pada kueri yang, saat mengembalikan lebih dari satu kolom, sering berjalan dalam rentang milidetik. Dan saya tidak akan terkejut jika hanya ada satu kali overhead (pemuatan kelas) dan dengan demikian perbedaan untuk permintaan (halaman) penuh jauh lebih sedikit.

— fietserwin
sumber

Perbedaan kinerja tidak begitu sederhana; lihat Membandingkan kinerja db_query dan db_select . Saya biasanya merekomendasikan db_query daripada db_select kecuali Anda memerlukan salah satu fitur khusus yang disebutkan dalam jawaban Berdir.

— geerlingguy