Apakah kita suka atau tidak, banyak atau tidak sebagian besar dari kita pengembang baik secara teratur bekerja dengan database atau mungkin harus bekerja dengan satu hari nanti. Dan mempertimbangkan jumlah penyalahgunaan dan penyalahgunaan di alam liar, dan volume pertanyaan terkait basis data yang muncul setiap hari, wajar untuk mengatakan bahwa ada konsep tertentu yang harus diketahui pengembang - bahkan jika mereka tidak merancang atau bekerja dengan basis data hari ini. Begitu:

Apa konsep penting yang harus diketahui oleh pengembang dan profesional perangkat lunak lain tentang basis data?

Pedoman untuk Tanggapan:

Buat daftar singkat.
Satu konsep per jawaban adalah yang terbaik.

Lebih spesifik .
"Pemodelan data" mungkin merupakan keterampilan yang penting , tetapi apa artinya tepatnya?

Jelaskan alasan Anda.
Mengapa konsep Anda penting? Jangan hanya mengatakan "gunakan indeks." Jangan jatuh ke dalam "praktik terbaik." Yakinkan audiens Anda untuk belajar lebih banyak.

Suara positif jawaban yang Anda setujui.
Baca dulu jawaban orang lain. Satu jawaban berperingkat tinggi adalah pernyataan yang lebih efektif daripada dua jawaban peringkat rendah. Jika Anda memiliki lebih banyak untuk ditambahkan, tambahkan komentar atau referensi yang asli.

Jangan downvote sesuatu hanya karena itu tidak berlaku untuk Anda secara pribadi.
Kita semua bekerja di domain yang berbeda. Tujuannya di sini adalah untuk memberikan arahan bagi para pemula basis data untuk mendapatkan pemahaman yang beralasan, pemahaman yang lengkap tentang desain basis data dan pengembangan yang digerakkan oleh basis data, bukan untuk bersaing memperebutkan gelar yang paling penting.

Hal pertama yang harus diketahui pengembang tentang basis data adalah ini: untuk apa basis data ? Bukan bagaimana cara kerjanya, atau bagaimana Anda membangunnya, atau bahkan bagaimana Anda menulis kode untuk mengambil atau memperbarui data dalam database. Tapi untuk apa mereka?

Sayangnya, jawaban untuk yang ini adalah target yang bergerak. Dalam heydey of databases, tahun 1970-an hingga awal 1990-an, database adalah untuk berbagi data. Jika Anda menggunakan database, dan Anda tidak membagikan data, Anda terlibat dalam proyek akademik atau Anda menyia-nyiakan sumber daya, termasuk diri Anda sendiri. Menyiapkan database dan menjinakkan DBMS adalah tugas yang sangat monumental sehingga hasilnya, dalam hal data dieksploitasi beberapa kali, harus sangat besar untuk mencocokkan investasi.

Selama 15 tahun terakhir, basis data telah digunakan untuk menyimpan data persisten yang terkait dengan hanya satu aplikasi. Membangun database untuk MySQL , atau Access , atau SQL Server telah menjadi sangat rutin sehingga database hampir menjadi bagian rutin dari aplikasi biasa. Terkadang, misi terbatas awal itu didorong ke atas oleh creep misi, karena nilai nyata dari data menjadi jelas. Sayangnya, database yang dirancang dengan tujuan tunggal sering gagal secara dramatis ketika mereka mulai didorong ke peran yang luas dan misi perusahaan yang kritis.

Hal kedua yang perlu dipelajari pengembang tentang basis data adalah seluruh tampilan data sentris dunia. Tampilan dunia data sentris lebih berbeda dari proses pandangan dunia sentris daripada apa pun yang pernah dipelajari sebagian besar pengembang. Dibandingkan dengan kesenjangan ini, kesenjangan antara pemrograman terstruktur dan pemrograman berorientasi objek relatif kecil.

Hal ketiga yang perlu dipelajari pengembang, setidaknya dalam tinjauan umum, adalah pemodelan data, termasuk pemodelan data konseptual, pemodelan data logis, dan pemodelan data fisik.

Pemodelan data konseptual adalah benar-benar analisis kebutuhan dari sudut pandang data sentris.

Pemodelan data logis umumnya adalah penerapan model data spesifik untuk persyaratan yang ditemukan dalam pemodelan data konseptual. Model relasional digunakan jauh lebih banyak daripada model spesifik lainnya, dan pengembang perlu mempelajari model relasional dengan pasti. Merancang model relasional yang kuat dan relevan untuk kebutuhan nontrivial bukan tugas sepele. Anda tidak dapat membangun tabel SQL yang baik jika Anda salah memahami model relasional.

Pemodelan data fisik umumnya adalah DBMS spesifik, dan tidak perlu dipelajari secara mendetail, kecuali pengembangnya juga pembuat basis data atau DBA. Apa yang perlu dipahami pengembang adalah sejauh mana desain basis data fisik dapat dipisahkan dari desain basis data logis, dan sejauh mana pembuatan basis data kecepatan tinggi dapat dicapai hanya dengan mengutak-atik desain fisik.

Hal berikutnya yang perlu dipelajari pengembang adalah bahwa sementara kecepatan (kinerja) penting, ukuran lain dari kebaikan desain bahkan lebih penting , seperti kemampuan untuk merevisi dan memperluas cakupan basis data di jalan, atau kesederhanaan pemrograman.

Akhirnya, siapa pun yang mengacaukan basis data perlu memahami bahwa nilai data sering kali lebih lama dari sistem yang menangkapnya .

Wah!

Pertanyaan bagus. Berikut ini adalah beberapa pemikiran tanpa urutan tertentu:

1. Normalisasi, setidaknya untuk bentuk normal kedua, sangat penting.

2. Integritas referensial juga penting, dengan menghapus cascading yang tepat dan memperbarui pertimbangan.

3. Penggunaan kendala pemeriksaan yang baik dan tepat. Biarkan database melakukan pekerjaan sebanyak mungkin.

4. Jangan sebarkan logika bisnis dalam database dan kode tingkat menengah. Pilih satu atau yang lain, lebih disukai di kode tingkat menengah.

5. Putuskan pendekatan yang konsisten untuk kunci utama dan kunci yang dikelompokkan.

6. Jangan over index. Pilih indeks Anda dengan bijak.

7. Penamaan tabel dan kolom yang konsisten. Pilih standar dan patuhi itu.

8. Batasi jumlah kolom dalam database yang akan menerima nilai nol.

9. Jangan terbawa oleh pemicu. Mereka memiliki penggunaannya tetapi dapat mempersulit hal-hal dengan tergesa-gesa.

10. Hati-hati dengan UDF. Mereka hebat tetapi dapat menyebabkan masalah kinerja ketika Anda tidak menyadari seberapa sering mereka dipanggil dalam permintaan.

11. Dapatkan buku Celko tentang desain basis data. Pria itu sombong tetapi tahu barang-barangnya.

Pertama, pengembang perlu memahami bahwa ada sesuatu yang perlu diketahui tentang database. Mereka bukan hanya perangkat ajaib tempat Anda meletakkan SQL dan keluar set hasil, tetapi potongan perangkat lunak yang sangat rumit dengan logika dan kebiasaan mereka sendiri.

Kedua, bahwa ada pengaturan basis data yang berbeda untuk tujuan yang berbeda. Anda tidak ingin pengembang membuat laporan historis dari basis data transaksional on-line jika ada data warehouse yang tersedia.

Ketiga, pengembang perlu memahami SQL dasar, termasuk gabungan.

Melewati ini, itu tergantung pada seberapa dekat pengembang terlibat. Saya telah bekerja di pekerjaan di mana saya adalah pengembang dan de facto DBA, di mana para DBA berada di ujung jalan, dan di mana para DBA berada di daerah mereka sendiri. (Saya tidak suka yang ketiga.) Dengan asumsi para pengembang terlibat dalam desain database:

Mereka perlu memahami normalisasi dasar, setidaknya tiga bentuk normal pertama. Lebih dari itu, dapatkan DBA. Bagi mereka yang memiliki pengalaman dengan ruang sidang AS (dan acara televisi acak dihitung di sini), ada mnemonik "Tergantung pada kunci, seluruh kunci, dan hanya kunci, jadi bantu Anda Codd."

Mereka perlu memiliki petunjuk tentang indeks, yang maksud saya mereka harus tahu indeks apa yang mereka butuhkan dan bagaimana mereka akan mempengaruhi kinerja. Ini berarti tidak memiliki indeks yang tidak berguna, tetapi tidak takut menambahkannya untuk membantu kueri. Apa pun lebih jauh (seperti saldo) harus dibiarkan untuk DBA.

Mereka perlu memahami kebutuhan akan integritas data, dan dapat menunjukkan ke mana mereka memverifikasi data dan apa yang mereka lakukan jika mereka menemukan masalah. Ini tidak harus ada dalam database (di mana akan sulit untuk mengeluarkan pesan kesalahan yang berarti bagi pengguna), tetapi harus ada di suatu tempat.

Mereka harus memiliki pengetahuan dasar tentang cara mendapatkan rencana, dan cara membacanya secara umum (setidaknya cukup untuk mengetahui apakah algoritma tersebut efisien atau tidak).

Mereka harus tahu secara samar apa pemicu itu, apa itu pandangan, dan bahwa mungkin untuk memecah-mecah basis data. Mereka tidak memerlukan detail apa pun, tetapi mereka perlu tahu untuk bertanya kepada DBA tentang hal-hal ini.

Mereka tentu saja harus tahu untuk tidak ikut campur dengan data produksi, atau kode produksi, atau semacamnya, dan mereka harus tahu bahwa semua kode sumber masuk ke dalam VCS.

Saya pasti lupa sesuatu, tetapi pengembang rata-rata tidak perlu menjadi DBA, asalkan ada DBA nyata di tangan.

Pengindeksan Dasar

Saya selalu terkejut melihat tabel atau seluruh database tanpa indeks, atau indeks arbitrer / tidak berguna. Sekalipun Anda tidak mendesain database dan hanya perlu menulis beberapa pertanyaan, masih sangat penting untuk dipahami, setidaknya:

• Apa yang diindeks dalam database Anda dan apa yang tidak:
• Perbedaan antara jenis pemindaian, bagaimana pemindaiannya, dan bagaimana cara Anda menulis kueri dapat memengaruhi pilihan itu;
• Konsep liputan (mengapa Anda tidak hanya menulis SELECT *);
• Perbedaan antara indeks berkerumun dan tidak berkerumun;
• Mengapa indeks lebih / lebih besar belum tentu lebih baik;
• Mengapa Anda harus mencoba menghindari membungkus kolom filter dalam fungsi.

Desainer juga harus mengetahui indeks umum anti-pola, misalnya:

• Anti-pola Access (mengindeks setiap kolom, satu per satu)
• Anti-pola Catch-All (satu indeks masif pada semua atau sebagian besar kolom, tampaknya dibuat di bawah kesan yang salah bahwa itu akan mempercepat setiap permintaan yang mungkin melibatkan setiap kolom itu).

Kualitas pengindeksan basis data - dan apakah Anda memanfaatkannya dengan kueri yang Anda tulis - sejauh ini merupakan bagian dari kinerja yang paling signifikan. 9 dari 10 pertanyaan yang diposting di SO dan forum lain mengeluh tentang kinerja yang buruk selalu berubah karena pengindeksan yang buruk atau ekspresi yang tidak mahal.

Normalisasi

Itu selalu membuat saya sedih melihat seseorang yang berjuang untuk menulis permintaan yang terlalu rumit yang akan sepenuhnya langsung dengan desain yang dinormalisasi ("Tunjukkan saya total penjualan per wilayah.").

Jika Anda memahami hal ini sejak awal dan merancang yang sesuai, Anda akan menghemat banyak rasa sakit nanti. Sangat mudah untuk mendenormalisasi kinerja setelah Anda menjadi normal; itu tidak mudah untuk menormalkan database yang tidak dirancang seperti itu sejak awal.

Paling tidak, Anda harus tahu apa itu 3NF dan bagaimana menuju ke sana. Dengan sebagian besar basis data transaksional, ini adalah keseimbangan yang sangat baik antara membuat kueri mudah ditulis dan mempertahankan kinerja yang baik.

Bagaimana Indeks Bekerja

Ini mungkin bukan yang paling penting, tapi pasti topik yang paling diremehkan.

Masalah dengan pengindeksan adalah bahwa tutorial SQL biasanya tidak menyebutkannya sama sekali dan bahwa semua contoh mainan berfungsi tanpa indeks apa pun.

Bahkan pengembang yang lebih berpengalaman dapat menulis SQL yang cukup bagus (dan kompleks) tanpa mengetahui lebih banyak tentang indeks daripada " Suatu indeks membuat kueri cepat ".

Itu karena database SQL melakukan pekerjaan yang sangat baik sebagai kotak hitam:

Katakan padaku apa yang kamu butuhkan (beri SQL), aku akan membereskannya.

Dan itu bekerja dengan sempurna untuk mengambil hasil yang benar. Penulis SQL tidak perlu tahu apa yang dilakukan sistem di belakang layar - sampai semuanya menjadi sangaaaat slooooow .....

Saat itulah pengindeksan menjadi topik. Tapi itu biasanya sangat terlambat dan seseorang (beberapa perusahaan?) Sudah menderita masalah nyata.

Itu sebabnya saya percaya pengindeksan adalah topik No. 1 yang tidak boleh dilupakan ketika bekerja dengan basis data . Sayangnya, sangat mudah untuk melupakannya.

Penolakan

Argumen dipinjam dari kata pengantar eBook gratis saya " Use The Index, Luke ". Saya menghabiskan banyak waktu untuk menjelaskan bagaimana indeks bekerja dan bagaimana menggunakannya dengan benar.

Saya hanya ingin menunjukkan sebuah pengamatan - yaitu sepertinya mayoritas respon menganggap database dapat dipertukarkan dengan basis data relasional. Ada juga database objek, database file datar. Penting untuk menilai kebutuhan proyek perangkat lunak yang ada. Dari perspektif programmer keputusan database dapat ditunda sampai nanti. Pemodelan data di sisi lain dapat dicapai sejak dini dan membawa banyak kesuksesan.

Saya pikir pemodelan data adalah komponen kunci dan merupakan konsep yang relatif lama namun merupakan salah satu yang telah dilupakan oleh banyak orang di industri perangkat lunak. Pemodelan data, terutama pemodelan konseptual, dapat mengungkapkan perilaku fungsional suatu sistem dan dapat diandalkan sebagai peta jalan untuk pengembangan.

Di sisi lain, jenis database yang dibutuhkan dapat ditentukan berdasarkan banyak faktor yang berbeda untuk memasukkan lingkungan, volume pengguna, dan perangkat keras lokal yang tersedia seperti ruang harddisk.

Menghindari injeksi SQL dan cara mengamankan basis data Anda

Setiap pengembang harus tahu bahwa ini salah: "Membuat profil operasi basis data sama sekali berbeda dengan kode profil."

Ada Big-O yang jelas dalam pengertian tradisional. Ketika Anda melakukan EXPLAIN PLAN(atau yang setara) Anda melihat algoritma. Beberapa algoritma melibatkan loop bersarang dan O ( n ^ 2). Algoritma lain melibatkan pencarian B-tree dan O ( n log n ).

Ini sangat, sangat serius. Sangat penting untuk memahami mengapa indeks penting. Ini penting untuk memahami pengorbanan kecepatan normalisasi-normalisasi. Sangat penting untuk memahami mengapa gudang data menggunakan skema bintang yang tidak dinormalisasi untuk pembaruan transaksional.

Jika Anda tidak jelas tentang algoritma yang digunakan lakukan hal berikut. Berhenti. Jelaskan rencana Eksekusi Kueri. Sesuaikan indeks sesuai.

Juga, akibatnya: Indeks Lebih Banyak Tidak Lebih Baik.

Terkadang indeks yang difokuskan pada satu operasi akan memperlambat operasi lainnya. Bergantung pada rasio dari dua operasi, menambahkan indeks mungkin memiliki efek yang baik, tidak ada dampak keseluruhan, atau merusak kinerja keseluruhan.

Saya pikir setiap pengembang harus memahami bahwa database memerlukan paradigma yang berbeda .

Saat menulis kueri untuk mendapatkan data Anda, pendekatan berbasis set diperlukan. Banyak orang dengan latar belakang interatif berjuang dengan ini. Namun, ketika mereka merangkulnya, mereka dapat mencapai hasil yang jauh lebih baik, meskipun solusinya mungkin bukan yang pertama kali muncul dengan sendirinya dalam pikiran mereka yang berfokus pada iteratif.

Pertanyaan yang sangat bagus Mari kita lihat, pertama tidak ada yang harus mempertimbangkan meminta basis data yang tidak sepenuhnya memahami bergabung. Itu seperti mengendarai mobil tanpa mengetahui di mana setir dan rem. Anda juga perlu tahu tipe data dan bagaimana memilih yang terbaik.

Hal lain yang harus dipahami oleh pengembang adalah bahwa ada tiga hal yang harus Anda pikirkan ketika mendesain database:

1. Integritas data - jika data tidak dapat diandalkan pada dasarnya Anda tidak memiliki data - ini berarti jangan masukkan logika yang diperlukan dalam aplikasi karena banyak sumber lain dapat menyentuh database. Kendala, kunci asing dan terkadang pemicu diperlukan untuk integritas data. Jangan gagal menggunakannya karena Anda tidak menyukainya atau tidak mau repot untuk memahaminya.

2. Kinerja - sangat sulit untuk memperbaiki database yang berkinerja buruk dan kinerja harus dipertimbangkan sejak awal. Ada banyak cara untuk melakukan kueri yang sama dan beberapa diketahui lebih cepat hampir selalu, sangat picik untuk tidak belajar dan menggunakan cara-cara ini. Baca beberapa buku tentang penyesuaian kinerja sebelum merancang kueri atau struktur basis data.

3. Keamanan - data ini adalah darah kehidupan perusahaan Anda, juga sering berisi informasi pribadi yang dapat dicuri. Belajarlah untuk melindungi data Anda dari serangan injeksi SQL dan penipuan serta pencurian identitas.

Saat meminta basis data, mudah untuk mendapatkan jawaban yang salah. Pastikan Anda memahami model data Anda secara menyeluruh. Ingat sering kali keputusan aktual dibuat berdasarkan data yang dikembalikan oleh kueri Anda. Ketika itu salah, keputusan bisnis yang salah dibuat. Anda dapat membunuh perusahaan dari pertanyaan buruk atau kehilangan pelanggan besar. Data memiliki makna, pengembang sering kelihatannya lupa akan hal itu.

Data hampir tidak pernah hilang, pikirkan dalam hal menyimpan data dari waktu ke waktu alih-alih hanya bagaimana mendapatkannya hari ini. Basis data yang berfungsi dengan baik ketika memiliki seratus ribu catatan, mungkin tidak begitu baik dalam sepuluh tahun. Aplikasi jarang bertahan selama data. Ini adalah salah satu alasan mengapa mendesain kinerja sangat penting.

Basis data Anda mungkin membutuhkan bidang yang tidak perlu dilihat oleh aplikasi. Hal-hal seperti GUID untuk replikasi, bidang tanggal dimasukkan. dll. Anda juga mungkin perlu menyimpan riwayat perubahan dan siapa yang membuatnya kapan dan dapat mengembalikan perubahan buruk dari gudang ini. Pikirkan tentang bagaimana Anda ingin melakukan ini sebelum Anda datang, tanyakan situs web bagaimana memperbaiki masalah di mana Anda lupa meletakkan klausa mana pada pembaruan dan memperbarui seluruh tabel.

Jangan pernah mengembangkan dalam versi database yang lebih baru daripada versi produksi. Tidak pernah, tidak pernah, tidak pernah berkembang secara langsung terhadap basis data produksi.

Jika Anda tidak memiliki administrator basis data, pastikan seseorang membuat cadangan dan tahu cara memulihkannya dan telah menguji memulihkannya.

Kode basis data adalah kode, tidak ada alasan untuk tidak menyimpannya dalam kontrol sumber sama seperti kode lainnya.

Desain Basis Data Evolusi. http://martinfowler.com/articles/evodb.html

Metodologi tangkas ini membuat proses perubahan basis data dapat dikelola, diprediksi, dan dapat diuji.

Pengembang harus tahu, apa yang diperlukan untuk membuat ulang basis data produksi dalam hal kontrol versi, integrasi berkelanjutan dan pengujian otomatis.

Proses Perancangan Basis Data Evolusi memiliki aspek administratif, misalnya sebuah kolom harus dijatuhkan setelah beberapa periode waktu seumur hidup di semua basis data dari basis kode ini.

Setidaknya tahu, bahwa konsep dan metodologi Database Refactoring ada. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Klasifikasi dan deskripsi proses memungkinkan untuk mengimplementasikan tooling untuk refactoring ini juga.

Dari pengalaman saya dengan basis data relasional, setiap pengembang harus tahu:

- Berbagai tipe data :

Menggunakan jenis yang tepat untuk pekerjaan yang benar akan membuat desain DB Anda lebih kuat, pertanyaan Anda lebih cepat dan hidup Anda lebih mudah.

- Pelajari tentang 1xM dan MxM :

Ini adalah roti dan mentega untuk basis data relasional. Anda perlu memahami hubungan satu-ke-banyak dan banyak-ke-banyak dan menerapkannya saat yang tepat.

- Prinsip " KISS " juga berlaku untuk DB :

Kesederhanaan selalu bekerja paling baik. Asalkan Anda telah mempelajari cara kerja DB, Anda akan menghindari kompleksitas yang tidak perlu yang akan menyebabkan masalah pemeliharaan dan kecepatan.

- Indeks :

Itu tidak cukup jika Anda tahu apa itu. Anda perlu memahami kapan menggunakannya dan kapan tidak.

juga:

• Aljabar Boolean adalah teman Anda
• Gambar: Jangan menyimpannya di DB. Jangan tanya kenapa.
• Tes HAPUS dengan SELECT

Saya ingin semua orang, baik DBA dan pengembang / desainer / arsitek, untuk lebih memahami cara memodelkan domain bisnis dengan benar, dan bagaimana memetakan / menerjemahkan model domain bisnis itu menjadi model logis basis data yang dinormalisasi, model fisik yang dioptimalkan, dan model kelas berorientasi objek yang tepat, yang masing-masing (dapat) berbeda, untuk berbagai alasan, dan memahami kapan, mengapa, dan bagaimana mereka (atau harus) berbeda satu sama lain.

Saya akan mengatakan keterampilan SQL dasar yang kuat. Saya telah melihat banyak pengembang sejauh ini yang tahu sedikit tentang database tetapi selalu meminta tips tentang cara merumuskan permintaan yang cukup sederhana. Pertanyaan tidak selalu semudah dan sesederhana itu. Anda harus menggunakan banyak gabungan (dalam, kiri, dll.) Saat menanyakan database yang dinormalisasi dengan baik.

Tentang komentar berikut untuk jawaban Walter M.:

"Ditulis dengan sangat baik! Dan perspektif historisnya bagus untuk orang-orang yang tidak melakukan pekerjaan basis data pada waktu itu (yaitu saya)".

Perspektif historis dalam arti tertentu sangat penting. "Mereka yang melupakan sejarah, ditakdirkan untuk mengulanginya." Cfr XML mengulangi kesalahan hierarkis di masa lalu, basis data grafik mengulangi kesalahan jaringan di masa lalu, sistem OO yang memaksakan model hierarkis pada pengguna sementara semua orang dengan hanya sepersepuluh otak harus tahu bahwa model hierarkis tidak cocok untuk umum- representasi tujuan dari dunia nyata, dan sebagainya, dan sebagainya.

Adapun pertanyaan itu sendiri:

Setiap pengembang database harus tahu bahwa "Relational" tidak sama dengan "SQL". Kemudian mereka akan mengerti mengapa mereka dikecewakan begitu parah oleh vendor DBMS, dan mengapa mereka harus memberitahu vendor yang sama untuk menghasilkan hal-hal yang lebih baik (misalnya DBMS yang benar-benar berhubungan) jika mereka ingin terus mengisap jumlah lucu dari uang dari pelanggan mereka untuk perangkat lunak jelek seperti itu).

Dan setiap pengembang database harus tahu segalanya tentang aljabar relasional. Maka tidak akan ada lagi pengembang tunggal yang harus memposting pertanyaan bodoh "Saya tidak tahu bagaimana melakukan pekerjaan saya dan ingin orang lain melakukannya untuk saya" di Stack Overflow lagi.

Saya pikir banyak detail teknis telah dibahas di sini dan saya tidak ingin menambahkannya. Satu hal yang ingin saya katakan adalah lebih sosial daripada teknis, jangan jatuh ke perangkap "DBA mengetahui yang terbaik" sebagai pengembang aplikasi.

Jika Anda mengalami masalah kinerja dengan kueri, ikutilah kepemilikan masalahnya. Lakukan riset Anda sendiri dan dorong agar DBA untuk menjelaskan apa yang terjadi dan bagaimana solusi mereka mengatasi masalah tersebut.

Munculkan saran Anda sendiri juga setelah Anda melakukan penelitian. Artinya, saya mencoba mencari solusi kooperatif untuk masalah daripada meninggalkan masalah database ke DBA.

Rasa hormat yang sederhana.

• Ini bukan hanya repositori
• Anda mungkin tidak tahu lebih baik dari vendor atau DBA
• Anda tidak akan mendukungnya jam 3 pagi dengan manajer senior meneriaki Anda

Pertimbangkan Denormalisasi sebagai malaikat yang mungkin, bukan iblis, dan juga pertimbangkan database NoSQL sebagai alternatif untuk database relasional.

Juga, saya pikir model Entity-Relation adalah harus-tahu untuk setiap pengembang bahkan jika Anda tidak mendesain database. Ini akan membuat Anda mengerti sepenuhnya tentang semua database Anda.

Jangan pernah memasukkan data dengan penyandian teks yang salah.

Setelah database Anda menjadi tercemar dengan banyak pengkodean, yang terbaik yang dapat Anda lakukan adalah menerapkan semacam kombinasi heuristik dan tenaga kerja manual.

Selain sintaks dan opsi konseptual yang mereka gunakan (seperti bergabung, memicu, dan prosedur tersimpan), satu hal yang akan sangat penting untuk setiap pengembang yang menggunakan database adalah ini:

Ketahui bagaimana mesin Anda akan melakukan kueri yang Anda tulis dengan spesifik.

Alasan saya pikir ini sangat penting hanyalah stabilitas produksi. Anda harus tahu bagaimana kinerja kode Anda sehingga Anda tidak menghentikan semua eksekusi di utas Anda sambil menunggu fungsi panjang selesai, jadi mengapa Anda tidak ingin tahu bagaimana kueri Anda akan mempengaruhi database, program Anda, dan mungkin bahkan server?

Ini sebenarnya adalah sesuatu yang telah memukul tim R&D saya lebih banyak daripada kehilangan titik koma atau sejenisnya. Anggapannya adalah permintaan akan mengeksekusi dengan cepat karena tidak pada sistem pengembangan mereka dengan hanya beberapa ribu baris dalam tabel. Bahkan jika database produksi memiliki ukuran yang sama, itu lebih dari kemungkinan akan digunakan lebih banyak, dan karenanya menderita kendala lain seperti beberapa pengguna mengaksesnya pada saat yang sama, atau ada yang salah dengan kueri lain di tempat lain, sehingga menunda hasil dari permintaan ini.

Bahkan hal-hal sederhana seperti bagaimana bergabung mempengaruhi kinerja kueri sangat berharga dalam produksi. Ada banyak fitur dari banyak mesin database yang membuat segalanya lebih mudah secara konsep, tetapi dapat memperkenalkan gotcha dalam kinerja jika tidak dipikirkan dengan jelas.

Ketahui proses eksekusi mesin database Anda dan rencanakan untuk itu.

Untuk pengembang profesional menengah yang banyak menggunakan basis data (menulis / memelihara kueri setiap hari atau hampir setiap hari), saya pikir harapannya harus sama dengan bidang lainnya: Anda menulis satu di perguruan tinggi .

Setiap C ++ geek menulis kelas string di perguruan tinggi. Setiap geek grafis menulis raytracer di perguruan tinggi. Setiap geek web menulis situs web interaktif (biasanya sebelum kami memiliki "kerangka kerja web") di perguruan tinggi. Setiap kutu buku perangkat keras (dan bahkan kutu buku perangkat lunak) membangun CPU di perguruan tinggi. Setiap dokter membedah seluruh mayat di perguruan tinggi, bahkan jika dia hanya akan mengambil tekanan darah saya dan mengatakan bahwa kolesterol saya terlalu tinggi hari ini. Mengapa basis data berbeda?

Sayangnya, mereka tampak berbeda, hari ini, untuk beberapa alasan. Orang-orang ingin .NET programmer mengetahui cara kerja string di C , tetapi internal RDBMS Anda seharusnya tidak terlalu mengkhawatirkan Anda .

Ini hampir mustahil untuk mendapatkan tingkat pemahaman yang sama hanya dengan membaca tentang mereka, atau bahkan bekerja dengan cara Anda turun dari atas. Tetapi jika Anda mulai dari bagian bawah dan memahami setiap bagian, maka relatif mudah untuk mencari tahu spesifik untuk basis data Anda. Bahkan hal-hal yang tidak bisa dilakukan oleh banyak geek basis data, seperti kapan menggunakan basis data non-relasional.

Mungkin itu agak ketat, terutama jika Anda tidak belajar ilmu komputer di perguruan tinggi. Saya akan nada beberapa: Anda bisa menulis hari ini , sepenuhnya, dari awal. Saya tidak peduli jika Anda mengetahui secara spesifik cara kerja pengoptimal kueri PostgreSQL, tetapi jika Anda cukup tahu untuk menulis sendiri, mungkin tidak akan terlalu berbeda dari apa yang mereka lakukan. Dan Anda tahu, menulis yang dasar itu benar-benar tidak sulit.

Urutan kolom dalam indeks non-unik adalah penting.

Kolom pertama haruslah kolom yang memiliki variabilitas paling banyak dalam isinya (yaitu kardinalitas).

Ini untuk membantu kemampuan SQL Server untuk membuat statistik yang berguna dalam cara menggunakan indeks saat runtime.

Pahami alat yang Anda gunakan untuk memprogram basis data !!!

Saya menghabiskan banyak waktu untuk memahami mengapa kode saya gagal secara misterius.

Jika Anda menggunakan .NET, misalnya, Anda perlu tahu cara menggunakan objek di System.Data.SqlClientnamespace dengan benar. Anda perlu tahu cara mengelola SqlConnectionobjek Anda untuk memastikan mereka dibuka, ditutup, dan bila perlu, dibuang dengan benar.

Anda perlu tahu bahwa ketika Anda menggunakan SqlDataReader, perlu untuk menutupnya secara terpisah dari Anda SqlConnection. Anda perlu memahami cara menjaga koneksi tetap terbuka saat yang tepat untuk cara meminimalkan jumlah hit ke database (karena mereka relatif mahal dalam hal waktu komputasi).

• Keahlian SQL dasar.
• Pengindeksan.
• Menangani berbagai inkarnasi DATE / TIME / TIMESTAMP.
• Dokumentasi driver JDBC untuk platform yang Anda gunakan.
• Menangani tipe data biner ( CLOB , BLOB , dll.)

Untuk beberapa proyek, dan model Object-Oriented lebih baik.

Untuk proyek lain, model Relasional lebih baik.

Masalah ketidakcocokan impedansi, dan tahu kekurangan umum atau ORM.

Kompatibilitas RDBMS

Lihat apakah diperlukan untuk menjalankan aplikasi di lebih dari satu RDBMS. Jika ya, mungkin perlu:

• hindari ekstensi RDBMS SQL
• menghilangkan pemicu dan prosedur penyimpanan
• ikuti standar SQL yang ketat
• mengonversi tipe data bidang
• mengubah tingkat isolasi transaksi

Kalau tidak, pertanyaan-pertanyaan ini harus ditangani secara terpisah dan versi (atau konfigurasi) aplikasi yang berbeda akan dikembangkan.

Jangan bergantung pada urutan baris yang dikembalikan oleh kueri SQL.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/