Melakukan perhitungan di MySQL vs PHP

Saya akan bermain dengan kekuatan masing-masing sistem.

Logika agregasi, penggabungan, dan pemfilteran jelas termasuk dalam lapisan data. Ini lebih cepat, bukan hanya karena sebagian besar mesin DB memiliki pengoptimalan 10+ tahun untuk melakukan hal itu, tetapi Anda meminimalkan data yang dialihkan antara DB dan server web Anda.

Di sisi lain, sebagian besar platform DB yang saya gunakan memiliki fungsionalitas yang sangat buruk untuk bekerja dengan nilai individual. Hal-hal seperti pemformatan tanggal dan manipulasi string hanya menyedot SQL, Anda lebih baik melakukannya di PHP.

Pada dasarnya, gunakan setiap sistem untuk tujuan yang dibangun.

Dalam hal pemeliharaan, selama pembagian antara apa yang terjadi di mana jelas, memisahkan ini ke jenis logika seharusnya tidak menimbulkan banyak masalah dan tentu saja tidak cukup untuk menghilangkan manfaat. Menurut pendapat saya, kejelasan dan pemeliharaan kode lebih tentang konsistensi daripada menempatkan semua logika di satu tempat.

Re:contoh spesifik...

1. Saya tahu ini bukan yang Anda maksudkan juga, tetapi tanggal hampir merupakan kasus khusus. Anda ingin memastikan bahwa semua tanggal yang dihasilkan oleh sistem dibuat baik di server web ATAU database. Melakukan sebaliknya akan menyebabkan beberapa bug berbahaya jika server db dan server web pernah dikonfigurasi untuk zona waktu yang berbeda (saya telah melihat ini terjadi). Bayangkan, misalnya, Anda memiliki createdDate kolom dengan default getDate() yang diterapkan pada sisipan oleh DB . Jika Anda memasukkan catatan, menggunakan tanggal yang dihasilkan di PHP (mis. date("Y-m-d", time() - 3600) , pilih rekaman yang dibuat dalam satu jam terakhir, Anda mungkin tidak mendapatkan apa yang Anda harapkan. Untuk lapisan mana Anda harus melakukan ini, saya lebih suka DB, seperti pada contoh, ini memungkinkan Anda menggunakan default kolom.

2. Untuk sebagian besar aplikasi saya akan melakukan ini di PHP. Menggabungkan nama depan dan nama belakang terdengar sederhana sampai Anda menyadari bahwa Anda terkadang membutuhkan salam, gelar, dan inisial tengah di sana juga. Plus Anda hampir pasti akan berakhir dalam situasi di mana Anda menginginkan nama depan pengguna, nama keluarga DAN gabungan salam + nama depan + nama keluarga. Menggabungkannya di sisi DB berarti Anda akhirnya memindahkan lebih banyak data, meskipun sebenarnya, ini cukup kecil.

3. Bergantung. Seperti di atas, jika Anda ingin menggunakannya secara terpisah, Anda sebaiknya menariknya keluar secara terpisah dan menggabungkannya saat diperlukan. Meskipun demikian, kecuali jika kumpulan data yang Anda tangani sangat besar, mungkin ada faktor lain (seperti, seperti yang Anda sebutkan, kemampuan perawatan) yang lebih berpengaruh.

Beberapa aturan praktis:

• Pembuatan id tambahan harus dilakukan di DB.
• Secara pribadi, saya suka default saya diterapkan oleh DB.
• Saat memilih, apapun yang mengurangi jumlah record harus dilakukan oleh DB.
• Biasanya baik untuk melakukan hal-hal yang mengurangi ukuran sisi DB set data (seperti dengan contoh string di atas).
• Dan seperti yang Anda katakan; pemesanan, agregasi, sub-kueri, gabungan, dll. harus selalu di sisi DB.
• Juga, kita belum membicarakannya tetapi pemicunya biasanya buruk/perlu.

Ada beberapa trade-off inti yang Anda hadapi di sini dan sisanya sangat tergantung pada aplikasi Anda.

Beberapa hal pasti-setiap-selalu dilakukan dalam SQL. Mengecualikan beberapa pengecualian (seperti tanggal) untuk banyak tugas SQL bisa sangat kikuk dan dapat meninggalkan Anda dengan logika di tempat yang tidak biasa. Saat menelusuri basis kode Anda untuk referensi ke kolom tertentu (misalnya) adalah mudah untuk melewatkan yang terkandung dalam tampilan atau prosedur tersimpan.

Performa selalu menjadi pertimbangan tetapi, tergantung pada aplikasi Anda dan contoh spesifiknya, mungkin bukan yang besar. Kekhawatiran Anda tentang pemeliharaan dan mungkin sangat valid dan beberapa manfaat kinerja yang saya sebutkan sangat sedikit, jadi waspadalah terhadap pengoptimalan prematur.

Juga, jika sistem lain mengakses DB secara langsung (misalnya untuk pelaporan, atau impor/ekspor), Anda akan mendapat manfaat dari memiliki lebih banyak logika dalam DB. Misalnya, jika Anda ingin mengimpor pengguna dari sumber data lain secara langsung, sesuatu seperti fungsi validasi email yang dapat digunakan kembali diimplementasikan di SQL.

Jawaban singkatnya:tergantung. :)