Kesalahan pengembangan basis data yang dilakukan oleh pengembang aplikasi [ditutup]


566

Apa kesalahan pengembangan database umum yang dilakukan oleh pengembang aplikasi?


Jawaban:


1002

1. Tidak menggunakan indeks yang sesuai

Ini relatif mudah tetapi tetap saja terjadi setiap saat. Kunci asing harus memiliki indeks pada mereka. Jika Anda menggunakan bidang dalam WHEREAnda harus (mungkin) memiliki indeks di dalamnya. Indeks semacam itu harus sering mencakup beberapa kolom berdasarkan kueri yang perlu Anda jalankan.

2. Tidak menegakkan integritas referensial

Basis data Anda mungkin berbeda di sini, tetapi jika basis data Anda mendukung integritas referensial - artinya semua kunci asing dijamin untuk menunjuk ke entitas yang ada - Anda harus menggunakannya.

Sangat umum untuk melihat kegagalan ini pada database MySQL. Saya tidak percaya MyISAM mendukungnya. InnoDB tidak. Anda akan menemukan orang-orang yang menggunakan MyISAM atau mereka yang menggunakan InnoDB tetapi tidak menggunakannya.

Lebih banyak di sini:

3. Menggunakan kunci primer alami daripada pengganti (teknis)

Kunci alami adalah kunci berdasarkan data yang bermakna secara eksternal yang (seolah-olah) unik. Contoh umum adalah kode produk, kode negara dua huruf (AS), nomor jaminan sosial dan sebagainya. Kunci pengganti atau teknis adalah yang sama sekali tidak memiliki makna di luar sistem. Mereka diciptakan murni untuk mengidentifikasi entitas dan biasanya bidang penambahan otomatis (SQL Server, MySQL, lainnya) atau urutan (terutama Oracle).

Menurut pendapat saya, Anda harus selalu menggunakan kunci pengganti. Masalah ini muncul dalam pertanyaan-pertanyaan ini:

Ini adalah topik yang agak kontroversial di mana Anda tidak akan mendapatkan persetujuan universal. Meskipun Anda mungkin menemukan beberapa orang, yang berpikir kunci alami dalam beberapa situasi OK, Anda tidak akan menemukan kritik terhadap kunci pengganti selain tidak perlu diperdebatkan. Kelemahan yang cukup kecil jika Anda bertanya kepada saya.

Ingat, bahkan negara dapat tidak ada lagi (misalnya, Yugoslavia).

4. Menulis pertanyaan yang mengharuskan DISTINCTuntuk bekerja

Anda sering melihat ini dalam kueri yang dihasilkan ORM. Lihat output log dari Hibernate dan Anda akan melihat semua pertanyaan dimulai dengan:

SELECT DISTINCT ...

Ini adalah sedikit jalan pintas untuk memastikan Anda tidak mengembalikan baris duplikat dan karenanya mendapatkan objek duplikat. Terkadang Anda akan melihat orang melakukan hal ini juga. Jika Anda melihatnya terlalu banyak itu adalah bendera merah nyata. Tidak DISTINCTburuk atau tidak memiliki aplikasi yang valid. Memang (pada kedua hitungan) tapi itu bukan pengganti atau penghenti sementara untuk menulis pertanyaan yang benar.

Dari Why I Bate DISTINCT :

Di mana segala sesuatunya mulai memburuk menurut pendapat saya adalah ketika pengembang membangun kueri yang substansial, bergabung dengan tabel bersama, dan tiba-tiba ia menyadari bahwa sepertinya ia mendapatkan duplikat (atau bahkan lebih) baris dan respons langsungnya ... "solusi" untuk "masalah" ini adalah membuang kata kunci DISTINCT dan POOF semua masalahnya hilang.

5. Mendukung agregasi daripada bergabung

Kesalahan umum lainnya oleh pengembang aplikasi database adalah tidak menyadari betapa lebih mahal agregasi (yaitu GROUP BYklausa) dapat dibandingkan dengan bergabung.

Untuk memberi Anda gambaran betapa meluasnya ini, saya telah menulis tentang topik ini beberapa kali di sini dan banyak downvoted untuk itu. Sebagai contoh:

Dari pernyataan SQL - "join" vs "group by and having" :

Kueri pertama:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

Waktu permintaan: 0,312 s

Kueri kedua:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

Waktu permintaan: 0,016 dtk

Betul. Versi gabungan yang saya usulkan dua puluh kali lebih cepat dari versi agregat.

6. Tidak menyederhanakan pertanyaan kompleks melalui tampilan

Tidak semua vendor database mendukung tampilan tetapi bagi mereka yang melakukannya, mereka dapat sangat menyederhanakan pertanyaan jika digunakan dengan bijaksana. Misalnya, pada satu proyek saya menggunakan model Partai generik untuk CRM. Ini adalah teknik pemodelan yang sangat kuat dan fleksibel tetapi dapat menyebabkan banyak bergabung. Dalam model ini ada:

  • Partai : orang dan organisasi;
  • Peran Pihak : hal-hal yang dilakukan pihak tersebut, misalnya Karyawan dan Majikan;
  • Party Role Relationship : bagaimana peran-peran tersebut saling terkait.

Contoh:

  • Ted adalah Orang, menjadi subtipe Partai;
  • Ted memiliki banyak peran, salah satunya adalah Karyawan;
  • Intel adalah sebuah organisasi, menjadi subtipe suatu Pihak;
  • Intel memiliki banyak peran, salah satunya adalah Majikan;
  • Intel mempekerjakan Ted, artinya ada hubungan antara peran mereka masing-masing.

Jadi ada lima meja yang bergabung untuk menghubungkan Ted dengan majikannya. Anda menganggap semua karyawan adalah Orang (bukan organisasi) dan memberikan pandangan penolong ini:

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

Dan tiba-tiba Anda memiliki pandangan yang sangat sederhana tentang data yang Anda inginkan tetapi pada model data yang sangat fleksibel.

7. Tidak membersihkan input

Ini sangat besar. Sekarang saya suka PHP tetapi jika Anda tidak tahu apa yang Anda lakukan, sangat mudah membuat situs yang rentan diserang. Tidak ada yang lebih baik dari kisah Bobby Tables yang kecil .

Data yang disediakan oleh pengguna melalui URL, data formulir, dan cookie harus selalu dianggap sebagai permusuhan dan disanitasi. Pastikan Anda mendapatkan apa yang Anda harapkan.

8. Tidak menggunakan pernyataan yang disiapkan

Pernyataan yang disiapkan adalah saat Anda mengkompilasi kueri dikurangi data yang digunakan dalam sisipan, pembaruan, dan WHEREklausa dan kemudian menyediakannya nanti. Sebagai contoh:

SELECT * FROM users WHERE username = 'bob'

vs.

SELECT * FROM users WHERE username = ?

atau

SELECT * FROM users WHERE username = :username

tergantung pada platform Anda.

Saya telah melihat database berlutut dengan melakukan ini. Pada dasarnya, setiap kali basis data modern menemukan kueri baru yang harus dikompilasinya. Jika memenuhi kueri yang terlihat sebelumnya, Anda memberi database kesempatan untuk men-cache permintaan yang dikompilasi dan rencana eksekusi. Dengan melakukan kueri banyak, Anda memberi kesempatan pada database untuk mencari tahu dan mengoptimalkannya (misalnya, dengan menyematkan kueri yang dikompilasi dalam memori).

Menggunakan pernyataan yang disiapkan juga akan memberi Anda statistik yang bermakna tentang seberapa sering kueri tertentu digunakan.

Pernyataan yang disiapkan juga akan lebih melindungi Anda terhadap serangan injeksi SQL.

9. Tidak cukup normal

Normalisasi basis data pada dasarnya adalah proses mengoptimalkan desain basis data atau cara Anda mengatur data ke dalam tabel.

Baru minggu ini saya menemukan beberapa kode di mana seseorang telah meledakkan array dan memasukkannya ke dalam satu bidang dalam database. Normalisasi itu akan memperlakukan elemen array itu sebagai baris terpisah dalam tabel anak (yaitu hubungan satu-ke-banyak).

Ini juga muncul dalam metode Terbaik untuk menyimpan daftar ID pengguna :

Saya telah melihat di sistem lain bahwa daftar ini disimpan dalam array PHP serial.

Tetapi kurangnya normalisasi muncul dalam banyak bentuk.

Lebih:

10. Normalisasi terlalu banyak

Ini mungkin tampak seperti kontradiksi dengan poin sebelumnya tetapi normalisasi, seperti banyak hal, adalah alat. Ini adalah sarana untuk mencapai tujuan dan bukan tujuan untuk mencapai tujuan itu sendiri. Saya pikir banyak pengembang melupakan ini dan mulai memperlakukan "cara" sebagai "akhir". Pengujian unit adalah contoh utama dari ini.

Saya pernah bekerja pada suatu sistem yang memiliki hierarki besar untuk klien yang berjalan seperti:

Licensee ->  Dealer Group -> Company -> Practice -> ...

sehingga Anda harus bergabung sekitar 11 tabel bersama sebelum Anda bisa mendapatkan data yang berarti. Itu adalah contoh bagus dari normalisasi yang diambil terlalu jauh.

Lebih penting lagi, denasionalisasi yang hati-hati dan dipertimbangkan dapat memiliki manfaat kinerja yang besar tetapi Anda harus benar-benar berhati-hati ketika melakukan ini.

Lebih:

11. Menggunakan busur eksklusif

Busur eksklusif adalah kesalahan umum di mana sebuah tabel dibuat dengan dua atau lebih kunci asing di mana satu dan hanya satu saja yang bisa non-nol. Kesalahan besar. Untuk satu hal, mempertahankan integritas data menjadi jauh lebih sulit. Setelah semua, bahkan dengan integritas referensial, tidak ada yang mencegah dua atau lebih kunci asing ini ditetapkan (terlepas dari kendala pemeriksaan kompleks).

Dari Panduan Praktis ke Desain Basis Data Relasional :

Kami telah sangat menyarankan terhadap konstruksi busur eksklusif sedapat mungkin, untuk alasan yang baik bahwa mereka bisa canggung untuk menulis kode dan menimbulkan lebih banyak kesulitan pemeliharaan.

12. Tidak melakukan analisis kinerja pada permintaan sama sekali

Pragmatisme berkuasa, terutama di dunia basis data. Jika Anda berpegang teguh pada prinsip-prinsip sampai-sampai mereka telah menjadi dogma maka kemungkinan besar Anda telah melakukan kesalahan. Ambil contoh kueri agregat dari atas. Versi agregat mungkin terlihat "bagus" tetapi kinerjanya menyedihkan. Perbandingan kinerja seharusnya mengakhiri perdebatan (tetapi tidak) tetapi lebih pada intinya: menyemburkan pandangan yang kurang informasi seperti itu pada awalnya adalah bodoh, bahkan berbahaya.

13. Ketergantungan berlebihan pada UNION ALL dan khususnya konstruksi UNION

UNION dalam istilah SQL hanya menggabungkan set data kongruen, yang berarti mereka memiliki jenis dan jumlah kolom yang sama. Perbedaan di antara mereka adalah bahwa UNION ALL adalah gabungan sederhana dan harus disukai sedapat mungkin sedangkan UNION secara implisit akan melakukan DISTINCT untuk menghapus duplikat tupel.

UNION, seperti DISTINCT, mendapatkan tempatnya. Ada aplikasi yang valid. Tetapi jika Anda menemukan diri Anda melakukan banyak hal, terutama di subqueries, maka Anda mungkin melakukan sesuatu yang salah. Itu mungkin kasus konstruksi kueri yang buruk atau model data yang dirancang dengan buruk yang memaksa Anda untuk melakukan hal-hal seperti itu.

UNION, khususnya ketika digunakan dalam gabungan atau subqueries dependen, dapat melumpuhkan database. Cobalah untuk menghindarinya sedapat mungkin.

14. Menggunakan kondisi ATAU dalam kueri

Ini mungkin tampak tidak berbahaya. Bagaimanapun, AND tidak masalah. ATAU seharusnya OK juga? Salah. Pada dasarnya kondisi DAN membatasi kumpulan data sedangkan kondisi ATAU menumbuhkannya tetapi tidak dengan cara yang cocok untuk optimasi. Terutama ketika kondisi ATAU yang berbeda mungkin berpotongan sehingga memaksa pengoptimal untuk secara efektif ke operasi yang berbeda pada hasilnya.

Buruk:

... WHERE a = 2 OR a = 5 OR a = 11

Lebih baik:

... WHERE a IN (2, 5, 11)

Sekarang pengoptimal SQL Anda dapat secara efektif mengubah kueri pertama menjadi kueri kedua. Tapi mungkin tidak. Tapi jangan lakukan itu.

15. Tidak merancang model data mereka untuk memberikan solusi berkinerja tinggi

Ini adalah titik sulit untuk diukur. Ini biasanya diamati oleh efeknya. Jika Anda menemukan diri Anda menulis kueri degil untuk tugas-tugas yang relatif sederhana atau bahwa permintaan untuk mengetahui informasi yang relatif mudah tidak efisien, maka Anda mungkin memiliki model data yang buruk.

Dalam beberapa hal, poin ini merangkum semua yang sebelumnya tetapi lebih merupakan kisah peringatan bahwa melakukan hal-hal seperti optimasi kueri sering dilakukan pertama kali ketika harus dilakukan kedua. Pertama dan terutama Anda harus memastikan Anda memiliki model data yang baik sebelum mencoba mengoptimalkan kinerja. Seperti yang Knuth katakan:

Optimalisasi prematur adalah akar dari semua kejahatan

16. Penggunaan Transaksi Database yang salah

Semua perubahan data untuk proses tertentu harus bersifat atom. Yaitu Jika operasi berhasil, ia melakukannya sepenuhnya. Jika gagal, data tidak berubah. - Seharusnya tidak ada kemungkinan perubahan 'setengah jadi'.

Idealnya, cara paling sederhana untuk mencapai ini adalah bahwa seluruh desain sistem harus berusaha untuk mendukung semua perubahan data melalui pernyataan INSERT / UPDATE / DELETE tunggal. Dalam hal ini, tidak diperlukan penanganan transaksi khusus, karena mesin database Anda harus melakukannya secara otomatis.

Namun, jika ada proses yang membutuhkan beberapa pernyataan dilakukan sebagai unit untuk menjaga data dalam keadaan yang konsisten, maka Kontrol Transaksi yang tepat diperlukan.

  • Mulai Transaksi sebelum pernyataan pertama.
  • Lakukan Transaksi setelah pernyataan terakhir.
  • Pada kesalahan apa pun, Kembalikan Transaksi. Dan sangat NB! Jangan lupa untuk melewatkan / membatalkan semua pernyataan yang mengikuti setelah kesalahan.

Juga disarankan untuk memperhatikan subtelties tentang bagaimana lapisan konektivitas basis data Anda, dan mesin basis data berinteraksi dalam hal ini.

17. Tidak memahami paradigma 'set-based'

Bahasa SQL mengikuti paradigma spesifik yang cocok untuk jenis masalah tertentu. Meskipun demikian, berbagai ekstensi khusus vendor, bahasa tersebut berjuang untuk menangani masalah yang sepele dalam bahasa seperti Java, C #, Delphi dll.

Kurangnya pemahaman ini memanifestasikan dirinya dalam beberapa cara.

  • Terlalu memaksakan terlalu banyak logika prosedural atau imperatif pada databse.
  • Penggunaan kursor yang tidak pantas atau berlebihan. Terutama ketika satu permintaan saja sudah mencukupi.
  • Berasumsi salah yang memicu kebakaran sekali per baris yang terpengaruh oleh pembaruan multi-baris.

Tentukan pembagian tanggung jawab yang jelas, dan berusaha untuk menggunakan alat yang tepat untuk menyelesaikan setiap masalah.


9
Pada pernyataan MySQL tentang kunci asing, Anda benar bahwa MyISAM tidak mendukungnya, tetapi Anda menyiratkan bahwa hanya menggunakan MyISAM adalah desain yang buruk. Alasan saya menggunakan MyISAM adalah karena InnoDB tidak mendukung pencarian FullText, dan saya pikir itu tidak masuk akal.
Derek H

1
Saya harus bertanya tentang # 6. Menggunakan pandangan seperti ini adalah salah satu hal favorit saya untuk dilakukan, tetapi saya baru-baru ini belajar, dengan ngeri, bahwa dengan indeks MySQL pada tabel yang mendasari hanya dipatuhi jika struktur tampilan memungkinkan penggunaan algoritma penggabungan. Jika tidak, tabel temp digunakan dan semua indeks Anda tidak berguna. Ini bahkan lebih mengkhawatirkan ketika Anda menyadari bahwa banyak operasi menyebabkan perilaku ini. Ini cara yang bagus untuk mengubah kueri 0,01 detik menjadi 100 detik. Apakah ada orang lain di sini yang memiliki pengalaman dengan ini? Periksa tautan di komentar saya berikutnya.
Peter Bailey

5
Sepenuhnya tidak setuju dengan # 3. Ya, negara bisa tidak ada lagi, tetapi kode negara akan terus mewakili hal yang sama. Sama dengan kode mata uang atau Amerika Serikat. Adalah bodoh untuk menggunakan kunci pengganti dalam kasus ini dan menciptakan lebih banyak overhead dalam kueri Anda karena Anda harus menyertakan tambahan bergabung. Saya akan mengatakan bahwa lebih aman untuk mengatakan bahwa Anda mungkin harus menggunakan pengganti untuk data khusus pengguna (dengan demikian, bukan negara, mata uang, dan AS).
Thomas

1
RE: # 11 Kendala pemeriksaan yang diperlukan untuk menegakkan integritas data adalah sepele. Ada alasan lain untuk menghindari desain itu, tetapi kebutuhan untuk kendala pemeriksaan "kompleks" bukan salah satunya.
Thomas

2
Dengan # 3 kamu tidak jujur. Ada lebih banyak kerugian pada kunci buatan daripada "Anda mungkin tidak membutuhkannya." Secara khusus, menggunakan kunci alami akan memberi Anda kemampuan untuk mengontrol urutan data di dalam tabel Anda ditulis ke disk. Jika Anda tahu bagaimana tabel Anda akan ditanyakan, Anda bisa mengindeksnya sehingga baris yang diakses secara bersamaan akan berakhir di halaman yang sama. Selanjutnya, Anda dapat menegakkan integritas data menggunakan indeks komposit unik. Jika Anda membutuhkan ini, Anda harus menambahkannya di samping indeks kunci buatan Anda. Jika kata indeks komposit adalah pkey Anda, maka 2 burung terbunuh dengan satu batu.
Shane H

110

Desain database utama dan kesalahan pemrograman yang dibuat oleh pengembang

  • Desain dan penggunaan basis data egois. Pengembang sering memperlakukan database sebagai objek penyimpanan pribadi mereka tanpa mempertimbangkan kebutuhan pemangku kepentingan lain dalam data. Ini juga berlaku untuk arsitek aplikasi. Desain basis data yang buruk dan integritas data menyulitkan pihak ketiga yang bekerja dengan data dan secara substansial dapat meningkatkan biaya siklus hidup sistem. Pelaporan dan SIM cenderung menjadi sepupu yang buruk dalam desain aplikasi dan hanya dilakukan sebagai renungan.

  • Menyalahgunakan data yang dinormalisasi. Melebih-lebihkan data yang dinormalisasi dan berusaha mempertahankannya di dalam aplikasi adalah resep untuk masalah integritas data. Gunakan denormalisasi dengan hemat. Tidak ingin menambahkan gabungan ke kueri bukan alasan untuk menormalisasi.

  • Takut menulis SQL. SQL bukanlah ilmu roket dan sebenarnya cukup baik dalam melakukan tugasnya. Lapisan pemetaan O / R cukup baik dalam melakukan 95% dari pertanyaan yang sederhana dan cocok dengan model itu. Terkadang SQL adalah cara terbaik untuk melakukan pekerjaan itu.

  • Kebijakan Dogmatic 'No Stored Procedures'. Terlepas dari apakah Anda percaya prosedur tersimpan itu jahat, sikap dogmatis semacam ini tidak ada dalam proyek perangkat lunak.

  • Tidak mengerti desain database. Normalisasi adalah teman Anda dan itu bukan ilmu roket. Bergabung dan kardinalitas adalah konsep yang cukup sederhana - jika Anda terlibat dalam pengembangan aplikasi database benar-benar tidak ada alasan untuk tidak memahaminya.


2
Orang mungkin berpendapat bahwa transaksi harus dilakukan dalam basis data transaksional dan pelaporan dan SIM harus dilakukan dalam database analisis terpisah. Karena itu, Anda mendapatkan yang terbaik dari kedua dunia dan semua orang senang (kecuali untuk mug miskin yang harus menulis skrip transformasi data untuk membangun yang terakhir dari yang sebelumnya).
Chris Simpson

Bukan hanya mug miskin yang menulis ETL - siapa pun yang menggunakan data dari sistem, data berkualitas buruk dalam aplikasi MIS yang dikemas karena beberapa hubungan kunci tidak benar-benar direkam pada sumbernya, siapa pun yang terlibat dalam rekonsiliasi bun-fignts tak berujung yang terjadi kemudian dari kualitas data yang buruk.
ConcernedOfTunbridgeWells

Saya tidak mungkin lebih tidak setuju dengan poin satu. Database adalah untuk ketekunan, mereka bukan untuk komunikasi antar-proses. Hampir selalu ada solusi yang lebih baik untuk masalah itu. Kecuali jika ada persyaratan eksplisit untuk itu, Anda benar-benar HARUS memperlakukan database seolah-olah tidak ada orang selain aplikasi Anda yang akan menggunakannya. Bahkan jika ADA persyaratan eksplisit, lakukan beberapa cerita pengguna dan analisis akar penyebabnya dan Anda akan sering menemukan cara yang jauh lebih baik untuk mengisi maksud pemohon. Kemudian lagi, saya bekerja di sebuah perusahaan di mana frasa CQRS agak umum
George Mauer

3
Contoh sepele: Saya memiliki sistem administrasi polis asuransi dan perlu memuat status 5 juta klaim ke dalam sistem reasuransi yang diserahkan untuk menghitung potensi pemulihan. Sistemnya adalah paket COTS client-server yang lebih lama, dirancang untuk antarmuka ke sistem mainframe yang lebih lama. Keduanya harus direkonsiliasi untuk tujuan kontrol keuangan. Pekerjaan ini dilakukan sebulan sekali. Dengan logika Anda, saya akan menulis serangkaian cerita pengguna yang mendefinisikan persyaratan dan meminta vendor untuk mengutip tentang menambahkan pembungkus layanan web untuk produk mereka yang ada.
ConcernedOfTunbridgeWells

2
Maka DBA Anda malas atau tidak kompeten.
ConcernedOfTunbridgeWells

80
  1. Tidak menggunakan kontrol versi pada skema database
  2. Bekerja langsung dengan database langsung
  3. Tidak membaca dan memahami konsep basis data yang lebih maju (indeks, indeks berkerumun, kendala, pandangan terwujud, dll)
  4. Gagal menguji skalabilitas ... data uji hanya 3 atau 4 baris tidak akan pernah memberi Anda gambaran nyata dari pertunjukan langsung nyata

1
Saya kedua, berat, # 1 dan # 2. Setiap kali saya melakukan perubahan pada DB saya membuang skema dan versinya; Saya memiliki tiga pengaturan database, satu dev, satu pementasan, dan satu hidup - TIDAK ADA yang pernah "diuji" pada DB hidup !!
Ixmatus

Di sini, di Red Gate kami telah mengambil langkah-langkah untuk meningkatkan poin pertama Anda dengan Kontrol Sumber SQL! Dari percakapan yang saya lakukan selama penelitian, saya pikir orang tidak lagi mengembangkan database produksi, tetapi sering kali perbaikan "darurat" dilakukan yang umumnya menemukan jalan mereka kembali ke lingkungan pengembangan, yang merupakan masalah lain.
David Atkinson

46

Penggunaan berlebihan dan / atau ketergantungan pada prosedur tersimpan.

Beberapa pengembang aplikasi melihat prosedur tersimpan sebagai perpanjangan langsung kode tingkat tengah / depan. Ini tampaknya menjadi sifat umum dalam pengembang tumpukan Microsoft, (saya salah, tapi saya sudah tumbuh dari itu) dan menghasilkan banyak prosedur tersimpan yang melakukan logika bisnis yang kompleks dan pemrosesan alur kerja. Ini jauh lebih baik dilakukan di tempat lain.

Prosedur tersimpan berguna di mana sebenarnya telah terbukti bahwa beberapa faktor teknis nyata mengharuskan penggunaannya (misalnya, kinerja dan keamanan) Misalnya, menjaga agregasi / penyaringan kumpulan data besar "dekat dengan data".

Saya baru-baru ini harus membantu memelihara dan meningkatkan aplikasi desktop Delphi besar yang 70% dari logika bisnis dan aturan diimplementasikan dalam 1400 prosedur tersimpan SQL Server (sisanya di event handler UI). Ini adalah mimpi buruk, terutama karena sulitnya memperkenalkan pengujian unit yang efektif untuk TSQL, kurangnya enkapsulasi dan alat yang buruk (Debuggers, editor).

Bekerja dengan tim Java di masa lalu saya dengan cepat menemukan bahwa sering kali kebalikan total terjadi di lingkungan itu. Seorang Arsitek Java pernah mengatakan kepada saya: "Basis data adalah untuk data, bukan kode."

Hari ini saya pikir itu kesalahan untuk tidak mempertimbangkan procs yang disimpan sama sekali, tetapi mereka harus digunakan hemat (tidak secara default) dalam situasi di mana mereka memberikan manfaat yang bermanfaat (lihat jawaban lain).


4
Prosedur tersimpan cenderung menjadi pulau luka dalam proyek mana pun mereka digunakan, sehingga beberapa pengembang membuat aturan "Tidak ada prosedur tersimpan". Jadi sepertinya ada konflik terbuka antara mereka. Jawaban Anda menjadi alasan yang baik untuk kapan sebenarnya memilih satu cara, atau yang lain.
Warren P

Manfaat: keamanan - Anda tidak harus memberi aplikasi kemampuan untuk "menghapus * dari ..."; tweak - DBA dapat mengubah permintaan tanpa harus mengkompilasi ulang / menggunakan seluruh aplikasi; analisis - mudah untuk mengkompilasi ulang sekelompok procs setelah perubahan model data untuk memastikan mereka masih valid; dan, akhirnya, mengingat SQL dijalankan oleh mesin database (bukan aplikasi Anda) maka konsep "database adalah untuk data, bukan kode" hanya terbelakang.
NotMe

Jadi, Anda akan menjebak logika bisnis Anda di UI, di mana itu bercerai dari data yang dimanipulasi? Ini sepertinya bukan ide yang bagus, terutama karena manipulasi data paling efisien ketika dilakukan oleh server database daripada dengan pulang-pergi dari UI. Itu juga berarti lebih sulit mengontrol aplikasi karena Anda tidak dapat mengandalkan database yang mengendalikan datanya dan berpotensi memiliki versi UI yang berbeda di luar sana dengan manipulasi data yang berbeda. Tidak baik. Saya tidak membiarkan apa pun menyentuh data saya kecuali melalui prosedur tersimpan.
David T. Macknet

Jika ada kebutuhan untuk pemisahan logika bisnis dari UI, arsitektur multi-tier dapat digunakan. Atau, perpustakaan dengan objek dan logika bisnis, yang digunakan oleh berbagai aplikasi / UI. Prosedur tersimpan mengunci data / logika bisnis Anda ke basis data tertentu, mengubah basis data dalam kasus ini sangat mahal. Dan biaya besar itu buruk.
juga

@ terlalu: Mengubah database dalam banyak kasus sangat mahal. Nevermind ide kehilangan kinerja dan fitur keamanan yang disediakan DBMS tertentu. Selanjutnya, tingkatan tambahan menambah kompleksitas dan mengurangi kinerja dan lapisan tambahan terikat dengan bahasa khusus Anda. Akhirnya, kemungkinan besar bahasa yang digunakan akan berubah daripada server database.
NotMe

41

Masalah nomor satu? Mereka hanya menguji pada database mainan. Jadi mereka tidak tahu bahwa SQL mereka akan merangkak ketika database menjadi besar, dan seseorang harus datang dan memperbaikinya nanti (suara yang bisa Anda dengar adalah gigiku menggigil).


2
Ukuran basis data relevan, tetapi masalah yang lebih besar adalah beban - bahkan jika Anda menguji pada dataset nyata Anda tidak menguji kinerja kueri Anda ketika database berada di bawah beban produksi, yang dapat menjadi pembuka mata yang nyata.
davidcl

Saya akan mengatakan bahwa ukuran basis data lebih besar daripada masalah memuat. Saya telah melihat berkali-kali, bahwa ada indeks penting yang hilang - tidak pernah ada masalah kinerja selama pengujian, karena seluruh basis data masuk ke dalam memori
Danubian Sailor


28

Kinerja Buruk Disebabkan oleh Subqueries yang Berhubungan

Sebagian besar waktu Anda ingin menghindari subquery yang berhubungan. Subquery berkorelasi jika, dalam subquery, ada referensi ke kolom dari kueri luar. Ketika ini terjadi, subquery dieksekusi setidaknya sekali untuk setiap baris yang dikembalikan dan bisa dieksekusi lebih banyak jika kondisi lain diterapkan setelah kondisi yang mengandung subquery berkorelasi diterapkan.

Maafkan contoh yang dibuat dan sintaksis Oracle, tetapi katakanlah Anda ingin menemukan semua karyawan yang telah dipekerjakan di salah satu toko Anda sejak terakhir kali toko melakukan kurang dari $ 10.000 penjualan dalam sehari.

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

Subquery dalam contoh ini berkorelasi dengan permintaan luar oleh store_id dan akan dieksekusi untuk setiap karyawan di sistem Anda. Salah satu cara query ini dapat dioptimalkan adalah dengan memindahkan subquery ke tampilan inline.

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

Dalam contoh ini, kueri dalam dari klausa sekarang menjadi inline-view (lagi beberapa sintaks khusus Oracle) dan hanya dijalankan sekali. Bergantung pada model data Anda, kueri ini mungkin akan mengeksekusi lebih cepat. Ini akan berkinerja lebih baik daripada permintaan pertama karena jumlah karyawan bertambah. Kueri pertama benar-benar dapat berkinerja lebih baik jika ada beberapa karyawan dan banyak toko (dan mungkin banyak toko tidak memiliki karyawan) dan tabel daily_sales diindeks di store_id. Ini bukan skenario yang mungkin tetapi menunjukkan bagaimana kueri yang berkorelasi dapat berkinerja lebih baik daripada alternatif.

Saya telah melihat pengembang junior mengkorelasikan subkueri berkali-kali dan biasanya berdampak besar pada kinerja. Namun, ketika menghapus subquery yang berkorelasi pastikan untuk melihat rencana menjelaskan sebelum dan sesudah untuk memastikan Anda tidak membuat kinerja lebih buruk.


1
Poin hebat, dan untuk menekankan salah satu poin terkait Anda - uji perubahan Anda. Belajar menggunakan menjelaskan rencana (dan melihat apa yang sebenarnya dilakukan database untuk mengeksekusi permintaan Anda, dan berapa biayanya), lakukan pengujian Anda pada dataset besar, dan jangan membuat SQL Anda terlalu rumit dan tidak terbaca / tidak dapat dipelihara untuk optimasi itu tidak benar-benar meningkatkan kinerja nyata.
Rob Whelan

21

Dalam pengalaman saya:
Tidak berkomunikasi dengan DBA yang berpengalaman.


17

Menggunakan Access alih-alih database "nyata". Ada banyak basis data kecil dan bahkan gratis seperti SQL Express , MySQL , dan SQLite yang akan bekerja dan berskala jauh lebih baik. Aplikasi sering perlu mengukur dengan cara yang tidak terduga.


16

Lupa mengatur hubungan antar tabel. Saya ingat harus membersihkan ini ketika saya mulai bekerja di perusahaan saya saat ini.


14

Menggunakan Excel untuk menyimpan (jumlah besar) data.

Saya telah melihat perusahaan memegang ribuan baris dan menggunakan beberapa lembar kerja (karena batas baris 65.535 pada versi Excel sebelumnya).


Excel sangat cocok untuk laporan, penyajian data, dan tugas lainnya, tetapi tidak boleh diperlakukan sebagai basis data.


14

Saya ingin menambahkan: Mendukung kode "Elegan" daripada kode berkinerja tinggi. Kode yang bekerja paling baik terhadap basis data seringkali jelek bagi mata pengembang aplikasi.

Percaya omong kosong tentang optimasi prematur. Database harus mempertimbangkan kinerja dalam desain asli dan dalam pengembangan selanjutnya. Kinerja adalah 50% dari desain basis data (40% adalah integritas data dan 10% terakhir adalah keamanan) menurut saya. Basis data yang tidak dibangun dari bawah ke atas untuk melakukan akan berkinerja buruk begitu pengguna nyata dan lalu lintas nyata ditempatkan terhadap database. Optimalisasi prematur tidak berarti tidak ada optimasi! Itu tidak berarti Anda harus menulis kode yang hampir selalu berkinerja buruk karena Anda merasa lebih mudah (kursor misalnya yang tidak boleh diizinkan dalam database produksi kecuali semua yang lain gagal). Ini berarti Anda tidak perlu melihat sedikit kinerja terakhir sampai Anda perlu. Banyak yang diketahui tentang apa yang akan berkinerja lebih baik pada basis data,


2
+1 - Pemrograman basis data mencakup pengoptimalan perilaku komponen mekanik. Namun, perlu diketahui bahwa Knuth mengatakan optimasi prematur adalah akar dari semua kejahatan sekitar 97% dari waktu (atau kata-kata untuk efek itu). Desain basis data adalah satu bidang di mana Anda benar-benar harus memikirkan hal ini di muka.
ConcernedOfTunbridgeWells

2
Ahem ... yang Anda bicarakan adalah optimasi yang tidak prematur. Beberapa pertimbangan penggunaan nyata diperlukan dari awal dalam desain database (dan desain aplikasi juga, sungguh). Aturan Knuth sebenarnya tidak sepele untuk diikuti, karena Anda harus memutuskan apa yang prematur dan apa yang tidak - itu benar-benar turun ke "jangan melakukan optimasi tanpa data". Keputusan terkait kinerja awal yang Anda bicarakan memiliki data - desain tertentu akan menetapkan batas yang tidak dapat diterima pada kinerja masa depan, dan Anda dapat menghitungnya.
Rob Whelan

13

Tidak menggunakan kueri parameterisasi. Mereka sangat berguna dalam menghentikan SQL Injection .

Ini adalah contoh spesifik untuk tidak membersihkan data input, yang disebutkan dalam jawaban lain.


3
Kecuali membersihkan input salah. Sanitasi berarti meletakkannya di tempat yang berbahaya. Parameterisasi berarti menjauhkannya dari jalur bahaya sama sekali.
Dustin

12

Aku benci ketika pengembang menggunakan pernyataan pilih bersarang atau bahkan berfungsi mengembalikan hasil pernyataan pilih di dalam bagian "SELECT" dari permintaan.

Saya benar-benar terkejut saya tidak melihat ini di tempat lain di sini, mungkin saya mengabaikannya, meskipun @adam memiliki masalah yang sama.

Contoh:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

Dalam skenario ini, jika MyTable mengembalikan 10.000 baris hasilnya adalah seolah-olah kueri hanya menjalankan 20001 kueri, karena harus menjalankan kueri awal ditambah kueri masing-masing tabel lainnya satu kali untuk setiap baris hasil.

Pengembang dapat pergi dengan ini bekerja dalam lingkungan pengembangan di mana mereka hanya mengembalikan beberapa baris data dan sub tabel biasanya hanya memiliki sejumlah kecil data, tetapi dalam lingkungan produksi, permintaan semacam ini dapat menjadi mahal secara eksponensial karena lebih data ditambahkan ke tabel.

Contoh yang lebih baik (belum tentu sempurna) akan menjadi seperti:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

Ini memungkinkan pengoptimal basis data untuk mengocok data bersama, daripada meminta kembali pada setiap catatan dari tabel utama dan saya biasanya menemukan ketika saya harus memperbaiki kode di mana masalah ini telah dibuat, saya biasanya akhirnya meningkatkan kecepatan permintaan sebesar 100% atau lebih banyak sekaligus mengurangi penggunaan CPU dan memori.


12

Untuk database berbasis SQL:

  1. Tidak memanfaatkan INDEKS CLUSTERED atau memilih kolom yang salah untuk CLUSTER.
  2. Tidak menggunakan datatype SERIAL (autonumber) sebagai PRIMARY KEY untuk bergabung dengan FOREIGN KEY (INT) dalam hubungan tabel induk / anak.
  3. Tidak MEMPERBARUI STATISTIK di atas meja ketika banyak catatan telah DIMASUKKAN atau DIHAPUS.
  4. Tidak mengatur ulang (mis. Unloading, droping, re-create, loading, dan re-indexing) tabel ketika banyak baris telah dimasukkan atau dihapus (beberapa mesin secara fisik menyimpan baris yang dihapus dalam sebuah tabel dengan flag delete.)
  5. Tidak memanfaatkan FRAGMENT ON EXPRESSION (jika didukung) pada tabel besar yang memiliki tingkat transaksi tinggi.
  6. Memilih tipe data yang salah untuk kolom!
  7. Tidak memilih nama kolom yang tepat.
  8. Tidak menambahkan kolom baru di akhir tabel.
  9. Tidak membuat indeks yang tepat untuk mendukung permintaan yang sering digunakan.
  10. membuat indeks pada kolom dengan beberapa nilai yang memungkinkan dan membuat indeks yang tidak perlu.
    ... lebih banyak untuk ditambahkan.

1
A quibble: 2) sebenarnya adalah praktik buruk. Saya mengerti apa yang Anda maksud - Anda ingin indeks unik pada autonumber itu, dan menggunakannya sebagai kunci pengganti. Tetapi kunci primer tidak boleh berupa autonumber, karena bukan itu primary key IS: kunci primer adalah "apa catatan tentang," yang (kecuali untuk hal-hal seperti transaksi penjualan) BUKAN autonumber, tetapi beberapa bit unik informasi tentang entitas yang dimodelkan.
David T. Macknet

alasan utama untuk menggunakan nomor otomatis untuk kunci utama dan kunci asing adalah untuk menjamin bahwa gabungan orangtua-anak dapat dipertahankan terlepas dari perubahan di kolom lainnya. menggunakan kunci utama yang berbeda, seperti nama pelanggan atau data lain bisa berisiko!
Frank R.

@ David: Saya berdiri dikoreksi! .. itu tidak perlu menggunakan autonumber sebagai kunci utama, seseorang masih dapat memiliki kolom serial yang diindeks pada orang tua, bergabung dengan pengganti pada anak untuk memastikan hubungan tidak akan terputus, sementara yang lain kolom sebagai primer yang bermakna untuk menemukan baris!
Frank R.

Ini adalah masalah semantik, pada akhirnya ... dan Microsoft lebih memilih kunci utama untuk menjadi tidak berarti, daripada bermakna. Perdebatan di sekitarnya mengamuk, tetapi saya jatuh ke dalam kamp "bermakna". :)
David T. Macknet

9
  • Tidak mengambil cadangan sebelum memperbaiki beberapa masalah di dalam basis data produksi.

  • Menggunakan perintah DDL pada objek yang disimpan (seperti tabel, tampilan) dalam prosedur tersimpan.

  • Takut menggunakan proc tersimpan atau takut menggunakan kueri ORM di mana pun lebih efisien / tepat untuk digunakan.

  • Mengabaikan penggunaan profiler basis data, yang dapat memberi tahu Anda secara persis apa yang dimaksud dengan kueri ORM Anda pada akhirnya dan karenanya memverifikasi logika atau bahkan untuk debugging saat tidak menggunakan ORM.


8

Tidak melakukan level normalisasi yang benar . Anda ingin memastikan bahwa data tidak digandakan, dan bahwa Anda membagi data menjadi berbeda sesuai kebutuhan. Anda juga perlu memastikan Anda tidak mengikuti normalisasi terlalu jauh karena itu akan merusak kinerja.


Seberapa jauh terlalu jauh? Jika tidak ada data yang digandakan, bagaimana Anda bisa mengambilnya lebih lanjut?
finnw

Normalisasi adalah keseimbangan menghapus data yang berlebihan dan meningkatkan fleksibilitas vs penurunan kinerja dan peningkatan kompleksitas. Menemukan keseimbangan yang tepat membutuhkan pengalaman dan berubah seiring waktu. Lihat en.wikipedia.org/wiki/Database_normalization untuk informasi kapan harus melakukan denormalkan
Nathan Voxland

8

Memperlakukan basis data hanya sebagai mekanisme penyimpanan (yaitu perpustakaan koleksi yang dimuliakan) dan karenanya tunduk pada aplikasi mereka (mengabaikan aplikasi lain yang berbagi data)


Akibat dari hal ini adalah memuat terlalu banyak pekerjaan query ke aplikasi alih-alih menyimpannya di db tempatnya. LINQ sangat buruk tentang ini.
3Dave

8
  • Mengabaikan ORM seperti Hibernate, karena alasan seperti "terlalu ajaib" atau "tidak ada di basis data saya ".
  • Mengandalkan terlalu banyak pada ORM seperti Hibernate dan mencoba untuk memilihnya di tempat yang tidak sesuai.

8

1 - Tidak perlu menggunakan fungsi pada nilai di mana klausa dengan hasil indeks yang tidak digunakan.

Contoh:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

dari pada

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

Dan pada tingkat lebih rendah: Tidak menambahkan indeks fungsional ke nilai-nilai yang membutuhkannya ...

2 - Tidak menambahkan batasan pemeriksaan untuk memastikan validitas data. Kendala dapat digunakan oleh pengoptimal kueri, dan mereka BENAR-BENAR membantu untuk memastikan bahwa Anda dapat mempercayai invarian Anda. Tidak ada alasan untuk tidak menggunakannya.

3 - Menambahkan kolom yang tidak dinormalisasi ke tabel karena kemalasan murni atau tekanan waktu. Hal-hal biasanya tidak dirancang dengan cara ini, tetapi berkembang menjadi ini. Hasil akhirnya, tanpa gagal, adalah satu ton pekerjaan yang mencoba untuk membersihkan kekacauan ketika Anda digigit oleh hilangnya integritas data dalam evolusi masa depan.

Pikirkan ini, tabel tanpa data sangat murah untuk dirancang ulang. Meja dengan beberapa juta catatan tanpa integritas ... tidak terlalu murah untuk dirancang ulang. Dengan demikian, melakukan desain yang benar saat membuat kolom atau tabel diamortisasi dalam sekop.

4 - tidak begitu banyak tentang database per se tetapi memang menjengkelkan. Tidak peduli dengan kualitas kode SQL. Fakta bahwa SQL Anda diekspresikan dalam teks tidak membuatnya OK untuk menyembunyikan logika dalam tumpukan algoritma manipulasi string. Sangat mungkin untuk menulis SQL dalam teks dengan cara yang sebenarnya dapat dibaca oleh sesama programmer Anda.


7

Ini telah dikatakan sebelumnya, tetapi: indeks, indeks, indeks . Saya telah melihat begitu banyak kasus aplikasi web perusahaan yang berkinerja buruk yang diperbaiki dengan hanya melakukan sedikit profil (untuk melihat tabel mana yang banyak terkena), dan kemudian menambahkan indeks pada tabel tersebut. Ini bahkan tidak memerlukan banyak cara pengetahuan menulis SQL, dan hasilnya sangat besar.

Hindari duplikasi data seperti wabah. Beberapa orang menganjurkan bahwa duplikasi kecil tidak akan sakit, dan akan meningkatkan kinerja. Hei, saya tidak mengatakan bahwa Anda harus menyiksa skema Anda ke dalam Bentuk Normal Ketiga, sampai begitu abstrak sehingga bahkan DBA tidak tahu apa yang terjadi. Hanya mengerti bahwa setiap kali Anda menduplikasi satu set nama, atau kode pos, atau kode pengiriman, salinan-salinan tersebut pada akhirnya tidak akan selaras satu sama lain. Itu akan terjadi. Dan kemudian Anda akan menendang diri sendiri saat Anda menjalankan skrip pemeliharaan mingguan.

Dan terakhir: gunakan konvensi penamaan yang jelas, konsisten, intuitif. Dengan cara yang sama bahwa sepotong kode yang ditulis dengan baik harus dapat dibaca, skema atau kueri SQL yang baik harus dapat dibaca dan secara praktis memberi tahu Anda apa yang dilakukannya, bahkan tanpa komentar. Anda akan berterima kasih pada diri sendiri dalam enam bulan, ketika Anda harus melakukan perawatan di atas meja. "SELECT account_number, billing_date FROM national_accounts"jauh lebih mudah untuk digunakan daripada "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".


Jika Anda mengaturnya dengan benar mereka tidak akan tetapi ini melibatkan penggunaan pemicu yang banyak orang alergi.
HLGEM

6

Tidak menjalankan kueri SELECT terkait sebelum menjalankan kueri DELETE (terutama pada basis data produksi)!


5

Kesalahan paling umum yang pernah saya lihat dalam dua puluh tahun: tidak merencanakan ke depan. Banyak pengembang akan membuat database, dan tabel, dan kemudian terus-menerus memodifikasi dan memperluas tabel saat mereka membangun aplikasi. Hasil akhirnya seringkali berantakan dan tidak efisien serta sulit dibersihkan atau disederhanakan nantinya.


1
Saya bisa membayangkan kengerian yang terjadi dalam situasi ini ... Database Schemaless jauh lebih cocok untuk prototyping cepat dan pengembangan berulang, tetapi seperti yang lainnya, fleksibilitas seperti itu datang dengan berbagai trade-off.
Zsolt Török

4

a) Nilai kueri Hardcoding dalam string
b) Menempatkan kode kueri basis data dalam aksi "OnButtonPress" dalam aplikasi Windows Forms

Saya telah melihat keduanya.


4
"Menempatkan kode permintaan DB dalam tindakan" OnButtonPress "dalam aplikasi Windows Form" Apa kesalahan basis data di sini?
rekursif

@recursive: ini adalah kerentanan injeksi SQL yang sangat besar. Siapa pun dapat mengirim SQL sewenang-wenang ke server Anda dan itu akan dijalankan kata demi kata.
Bill Karwin

Setuju dengan @recursive. Ini benar-benar tidak ada hubungannya dengan masalah DB.
p.campbell

b) adalah kesalahan arsitektur. Tentu saja, menyandi kueri langsung di aplikasi Anda adalah ide yang buruk.
3Dave

4

Tidak cukup memperhatikan pengelolaan koneksi database di aplikasi Anda. Kemudian Anda mengetahui aplikasi, komputer, server, dan jaringan yang tersumbat.


4
  1. Berpikir bahwa mereka adalah DBA dan pemodel / desainer data ketika mereka tidak memiliki indoktrinasi formal apa pun di bidang-bidang tersebut.

  2. Berpikir bahwa proyek mereka tidak memerlukan DBA karena hal-hal itu mudah / sepele.

  3. Kegagalan untuk membedakan antara pekerjaan yang seharusnya dilakukan dalam database, dan pekerjaan yang harus dilakukan dalam aplikasi.

  4. Tidak memvalidasi cadangan, atau tidak mencadangkan.

  5. Menanamkan SQL mentah dalam kode mereka.



3

Tidak memiliki pemahaman tentang model konkurensi database dan bagaimana ini mempengaruhi pengembangan. Sangat mudah untuk menambahkan indeks dan men-tweak permintaan setelah fakta. Namun aplikasi yang dirancang tanpa pertimbangan yang tepat untuk hotspot, pertentangan sumber daya dan operasi yang benar (Dengan asumsi apa yang baru saja Anda baca masih valid!) Dapat memerlukan perubahan signifikan dalam database dan tingkat aplikasi untuk dikoreksi nanti.


3

Tidak mengerti bagaimana DBMS bekerja di bawah tenda.

Anda tidak dapat menggerakkan tongkat dengan benar tanpa memahami cara kerja kopling. Dan Anda tidak dapat memahami cara menggunakan Database tanpa memahami bahwa Anda benar-benar hanya menulis ke file di hard disk Anda.

Secara khusus:

  1. Apakah Anda tahu apa itu Indeks Clustered? Apakah Anda memikirkannya ketika Anda merancang skema Anda?

  2. Apakah Anda tahu cara menggunakan indeks dengan benar? Bagaimana cara menggunakan kembali indeks? Apakah Anda tahu apa itu Indeks Penutupan?

  3. Sangat bagus, Anda memiliki indeks. Seberapa besar 1 baris dalam indeks Anda? Seberapa besar indeks ketika Anda memiliki banyak data? Apakah itu mudah masuk ke memori? Jika tidak, itu tidak berguna sebagai indeks.

  4. Apakah Anda pernah menggunakan EXPLAIN di MySQL? Bagus. Sekarang jujurlah dengan diri sendiri: Apakah Anda mengerti bahkan setengah dari apa yang Anda lihat? Tidak, kamu mungkin tidak. Perbaiki itu.

  5. Apakah Anda memahami Query Cache? Apakah Anda tahu apa yang membuat kueri tidak dapat dijangkau?

  6. Apakah Anda menggunakan MyISAM? Jika Anda MEMBUTUHKAN pencarian teks lengkap, MyISAM adalah omong kosong. Gunakan Sphinx. Kemudian beralih ke Inno.


2
Analogi yang lebih baik mungkin adalah bahwa seseorang tidak dapat dengan benar memecahkan masalah transmisi manual tanpa memahami kopling. Banyak orang yang benar-benar menggerakkan tongkat tanpa tahu bagaimana cara kerja kopling.
Michael Easter

3
  1. Menggunakan ORM untuk melakukan pembaruan massal
  2. Memilih lebih banyak data dari yang dibutuhkan. Sekali lagi, biasanya dilakukan saat menggunakan ORM
  3. Memecat sqls dalam satu lingkaran.
  4. Tidak memiliki data pengujian yang baik dan hanya melihat penurunan kinerja pada data langsung.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.