Saat menggunakan ORM, beberapa hal yang harus diperhatikan dalam desain basis data Anda

Apa sajakah desain database yang harus diperhatikan ketika Anda tahu bahwa database akan diakses menggunakan Object Relational Mapper (ORM) Wikipedia ? Juga lihat Entity Framework NHibernate atau LLBLGenPro.

Sebagai contoh, saya akan mencatat batas parameter 2100 pada panggilan RPC SqlServer. Ini adalah masalah ketika menggunakan LLBLgen dan tabel bergabung ketika kunci primer majemuk digunakan lihat artikel MSDN untuk kunci majemuk .

Pergi melalui teknik normalisasi standar, terutama ke bentuk normal ke-3. Beberapa ORM dapat menangkap hubungan yang ditentukan pada tingkat basis data sehingga Anda tidak perlu secara manual.

Saya akan benar-benar pergi ke arah lain dan bertanya apa yang harus saya ketahui tentang ORM. Pastikan Anda tahu: - Bagaimana cara membuat profil kueri? - Bagaimana saya bisa mengganti ORM dan menulis permintaan saya sendiri? - Bisakah saya menggunakan procs yang disimpan sebagai gantinya?

Database harus ORN agnostik karena, kemungkinan besar, itu akan bertahan lebih lama dari aplikasi.

1. Jangan pernah ORM membuat atau memperbarui skema. Selalu gunakan SQL yang dihasilkan sebagai templat tetapi telusuri sebelum membuat perubahan (Saya telah melihat ORM kami membuat indeks yang berlebihan, gunakan tipe data yang buruk ... semua hal buruk itu)

2. Waspadai apa yang tidak dapat dilakukan oleh ORM Anda. Django untuk sementara waktu tidak mendukung grup melalui ORM yang menyusahkan (tetap saja, sistem legacy menyenangkan!). Jadi menyadari keterbatasan ORM adalah suatu keharusan bagi DBA bahkan jika mereka bukan orang yang menulis kode untuk ORM

3. Secara berkala, ambil log lambat Anda, gabungkan mereka melalui mysqlslowlog, dan lihat 10 teratas. Pada dasarnya ini akan menunjukkan kepada Anda pertanyaan yang memakan waktu paling banyak secara keseluruhan. Kueri yang hanya membutuhkan rata-rata 1 detik tetapi berjalan 50 ribu kali dalam sebulan terakhir akan mencuat pada laporan agregat itu seperti jempol yang sakit;)

Saya tidak akan mengatakan terlalu ekstrim untuk membuang ORM sepenuhnya. Jika pengembang Anda menggunakan ORM bukan DBA, mereka cenderung menulis SQL yang lebih buruk atau lebih buruk daripada ORM. Jadi pada akhirnya akan jatuh pada DBA untuk menonton apa yang terjadi.

Ada beberapa hal yang saya perhatikan segera tentang database lama yang berbeda dari database yang dibuat oleh ORM seperti Sequel dan ActiveRecord untuk Ruby.

1. Penggunaan kunci utama di semua tabel disebut 'id'. Ya, itu bisa diganti, tetapi idmerupakan default.
2. Penggunaan nama jamak untuk tabel.
3. Penggunaan garis bawah ("snakecase") untuk memisahkan kata-kata yang menciptakan nama deskriptif dari tabel dan bidang.
4. Penggunaan _idditambahkan ke kunci asing: Tata letaknya biasanya seperti referenced_table_id.

Saya telah menulis SQL dengan tangan saya selama bertahun-tahun karena saya tidak mempercayai ORM, tetapi selama dua atau tiga terakhir saya mulai menggunakan dua ORM yang disebutkan sebelumnya, dan saya terkesan dengan seberapa baik mereka berintegrasi dengan database yang ada, dan seberapa baik mereka dapat menguraikan database jika konvensi mereka diikuti, atau saya meluangkan waktu untuk memberi mereka petunjuk yang diperlukan untuk memahami DB warisan.

Saya tidak tahu apakah ada pedoman umum untuk merancang skema agar bermain baik dengan ORM, tapi saya pikir kita semua akan mendapat manfaat dengan memiliki beberapa standar. Pasti ada waktu dan tempat untuk ORM, terutama jika Anda menggunakan bahasa OO yang baik dan Anda berada di jadwal yang ketat.

Tergantung (:)) sedikit pada apa ATAU mapper yang Anda gunakan, jadi luangkan waktu untuk meneliti fitur db mapper OR apa yang didukung / tidak didukung.

Misalnya, pemetaan Microsoft ATAU tidak mendukung semua tipe data bawaan SQL Server, tidak mendukung beberapa fitur TSQL yang lebih baru / canggih (kueri rekursif, petunjuk pengoptimal, dll. Muncul dalam pikiran).

Secara teori , seorang ATAU mapper yang baik harus cukup fleksibel untuk mengatasi (dan memungkinkan Anda untuk memetakan) skema database relasional yang dirancang dengan baik untuk model objek yang baik. Pada kenyataannya, kita masih harus sedikit sebelum semua potongan puzzle ada di tempatnya; meskipun banyak ATAU pembuat peta mendukung pemetaan tingkat lanjut, pemetaan itu sering kali dilakukan dengan mengorbankan pertanyaan yang rumit dan masalah kinerja.

Untuk kinerja db yang baik (dan untuk menjaga kewarasan dba :)), Anda harus tetap mengikuti praktik terbaik dalam hal desain skema db; normalisasikan dulu dan denormalkan di mana [/ jika] perlu. Di sisi kode, jangan berlebihan dengan model objek Anda ; bahkan jika ATAU mapper mendukung model pewarisan kompleks dan entitas yang menggabungkan banyak tabel bersama, ini juga area di mana Anda berisiko mengalami masalah dengan kueri yang terlalu rumit mengenai database dll. Profil, profil, profil, dan jangan hanya mengambil ORM permintaan yang dihasilkan begitu saja. Ingatlah bahwa ATAU kueri yang dihasilkan mapper sering dapat diubah seperti kueri SQL normal dan bahwa dua kueri yang secara fungsional setara di sisi objek (mis. Kueri linq) terkadang dapat menghasilkan kueri SQL yang sangat berbeda.