Ada banyak hal yang perlu diingat saat Anda mendesain database, dan sangat sedikit dari kita yang dapat mengingat setiap tip dan trik berharga yang telah kita pelajari. Jadi, mari kita lihat beberapa sumber online yang menampilkan tip desain database dan praktik terbaik. Saat kita pergi, saya akan membagikan pendapat saya sendiri tentang ide-ide yang disajikan, berdasarkan pengalaman saya dalam desain database.
Jelas, artikel ini bukan daftar lengkap, tetapi saya telah mencoba meninjau dan mengomentari berbagai sumber. Semoga, Anda akan menemukan informasi yang paling sesuai dengan kebutuhan dan tujuan Anda.
Sebagai catatan tambahan, saya terkejut menemukan bahwa banyak artikel yang terkait dengan praktik desain basis data memiliki sedikit contoh; sumber daya online yang saya ulas untuk artikel tentang kesalahan dan kesalahan memiliki persentase yang lebih tinggi. Kekurangan ini merupakan kelemahan, karena contoh sangat penting untuk menyampaikan maksud.
Kiat Basis Data untuk Desainer Berpengalaman
Pertama, mari kita mulai dengan sumber yang menampilkan tip desain database tingkat lanjut dan praktik terbaik. Ini untuk desainer yang sudah bekerja dalam pemodelan data dan telah bekerja selama beberapa waktu. Beberapa artikel ditujukan untuk tingkat yang lebih menengah, tetapi jika membahas konsep lanjutan, saya telah memasukkannya ke dalam daftar ini.
Pedoman Basis Data (RDBMS/SQL)
oleh Steve Djajasaputra | SOA, Java, Pengembangan Perangkat Lunak – BlogSpot | 16 Januari 2013
Artikel dari Pak Djajasaputra ini cukup mengesankan:ia mencantumkan banyak tips untuk skema, indeks, dan tampilan; dia juga menyediakan konvensi penamaan yang cukup rinci. Dan tipsnya terus berlanjut (dan terus berlanjut). Luasnya mengesankan, tetapi hampir tidak ada contoh. Beberapa poinnya mungkin dapat diperdebatkan, tetapi secara keseluruhan ini adalah presentasi yang sangat solid.
Secara khusus, saya terkesan bahwa dia memberikan aturan yang tepat tentang penggunaan kunci primer alami versus buatan (yaitu, pengganti atau yang dibuat). Dia membuat ini bagus dan sederhana, dengan menetapkan bahwa kita harus memilih kunci alami karena itu bermakna. Dia juga memberikan panduan untuk penggunaan terbaik dari kunci buatan – khususnya, ketika kunci alami tidak unik atau ketika Anda perlu mengubah nilai kunci alami. Dengan kata-katanya sendiri:
Pertama lebih suka menggunakan kunci alami karena lebih bermakna dan untuk menghindari duplikasi (menggunakan kembali kolom yang ada). Tetapi ada beberapa kasus ketika Anda membutuhkan kunci buatan:ketika kunci alami tidak unik (mis., Nama) atau jika Anda perlu mengubah nilainya.Karena daftar tipnya sangat panjang, saya tidak bisa membayangkan mengingat semuanya. Tetapi setiap bagian dapat direferensikan saat Anda mengerjakan desain basis data, kinerja, prosedur tersimpan, dan pembuatan versi. Ada juga bagian tentang poin khusus Oracle yang akan berguna jika Anda bekerja dengan atau berencana untuk mendukung Oracle.
Secara keseluruhan, ini adalah sumber yang sangat berharga dan komprehensif.
9 Tips untuk Desain Database yang Lebih Baik
oleh Jeffrey Edison | Vertabelo Blog | 22 September 2015
Saya akan menikmati sedikit promosi diri di sini.
Artikel berisi 9 tips untuk desain database yang lebih baik ini berdasarkan pengalaman saya sebagai desainer dan arsitek. Saya juga menemukan wawasan tambahan dari meneliti praktik terbaik orang lain untuk desain database.
Daftar saya mewakili beberapa masalah utama yang dapat terjadi saat bekerja dengan model data. Saya mengatur tip dalam urutan kemunculannya selama siklus hidup proyek (bukan berdasarkan kepentingan atau seberapa sering mereka muncul) karena itu akan sangat berguna, setidaknya menurut pandangan saya. Pembaca dapat mengikuti daftar periksa praktik terbaik ini melalui siklus hidup proyek.
Dari artikel:
Mengutip Al Capone (atau John Van Buren, putra Presiden AS ke-8), "uji lebih awal, sering uji". Dengan cara ini, Anda mengikuti jalur Integrasi Berkelanjutan. Pengujian pada tahap pengembangan awal menghemat waktu dan uang. Dalam menguji database, tujuannya adalah untuk mensimulasikan lingkungan produksi:“A Day in the Life of the Database”. Berapa volume yang bisa diharapkan? Interaksi pengguna apa yang mungkin terjadi? Apakah kasus perbatasan sedang ditangani?Dengan memperhatikan tip-tip ini, saya telah menemukan bahwa database menjadi dirancang lebih baik dan lebih kuat. Meskipun tidak satu pun dari aktivitas ini akan memakan banyak waktu, masing-masing dapat memiliki dampak yang sangat besar pada kualitas model data Anda.
Saya harap daftar tips saya berguna untuk desainer tingkat menengah dan lanjutan.
20 Praktik Terbaik Desain Basis Data
oleh Cagdas Basaraner | Saldo Kode – BlogSpot | 24 Juli 2011
Mr Basaraner menyajikan kepada kita daftar menarik dari 20 praktik terbaik desain database. Saya lebih suka jika dia mengelompokkan beberapa di antaranya; misalnya, empat item pertama semuanya dapat tercakup dalam “Gunakan Konvensi Pemberian Nama yang Baik”.
Selain itu, ia menyatakan bahwa menggunakan ID sintetis yang dihasilkan (bilangan bulat) sebagai kunci utama dari semua tabel adalah praktik terbaik. Faktanya, ini masih menjadi topik perdebatan, dengan argumen pro dan kontra. Beberapa praktik terbaiknya cukup umum, seperti "Untuk ... sistem basis data kritikus misi [sic], gunakan pemulihan bencana dan layanan keamanan ..." Saya tidak setuju dengan poin ini, tetapi ini adalah level yang sangat tinggi.
Di sisi positifnya, artikel ini adalah salah satu dari sedikit yang menyebutkan menggunakan kerangka kerja pemetaan relasional objek (ORM). Beberapa komentator tidak setuju dengan bagaimana tip itu diucapkan, tetapi setidaknya menggunakan kerangka kerja ORM disebutkan:
Gunakan kerangka kerja ORM (pemetaan relasional objek) (mis., Hibernate, iBatis ...) jika kode aplikasi cukup besar. Masalah kinerja kerangka kerja ORM dapat ditangani dengan parameter konfigurasi terperinci.Namun, daftar ini dapat diperbaiki. Itu harus dengan jelas mengidentifikasi poin yang spesifik hanya untuk beberapa sistem manajemen basis data (misalnya, SQL Server). Statistik yang tepat mengenai kinerja, heuristik, atau pentingnya menghabiskan waktu untuk desain bukan pada pemeliharaan dan desain ulang akan baik. Lebih banyak contoh diperlukan juga, tetapi itu adalah masalah untuk sebagian besar artikel ini.
Jika Anda bekerja dengan SQL Server, mempertimbangkan untuk menggunakan kerangka kerja ORM, atau memerlukan daftar tips daripada artikel yang panjang dan mendetail, maka artikel ini cocok untuk Anda.
(Catatan:artikel ini juga muncul di beberapa situs lain, termasuk CodeBuild, Java Code Geeks, dan DZone.)
Dasar-Dasar Desain Basis Data. 10 Hal yang Harus Anda Lakukan
oleh Michelle A. Poolet | SQL Server Pro | 1 Maret 2011
Sebagian dari tips Ms. Poolet cukup standar dan dapat ditemukan di banyak sumber lain, tetapi ada beberapa poin yang agak tidak umum juga. Di antara poin generiknya, dia mempromosikan penggunaan sub-tipe dan super-tipe (yang sangat saya setujui) karena ini mencerminkan desain berorientasi objek dan dapat dengan mudah dipahami oleh pengembang. Dari artikelnya:
Jangan takut untuk menyertakan entitas supertipe dan subtipe dalam desain Anda di CDM dan seterusnya. Subtipe mewakili klasifikasi atau kategori supertipe… Entitas direpresentasikan sebagai subtipe ketika dibutuhkan lebih dari satu kata atau frasa untuk mengkategorikan entitas.
Jika suatu kategori memiliki kehidupannya sendiri, dengan atribut terpisah yang menjelaskan bagaimana kategori terlihat dan berperilaku serta memisahkan hubungan dengan entitas lain, maka inilah saatnya untuk memanggil struktur supertipe/subtipe . Kegagalan untuk melakukannya akan menghambat pemahaman yang lengkap tentang data dan aturan bisnis yang mendorong pengumpulan data.
Beberapa komentarnya membuat referensi khusus ke MS SQL Server meskipun komentar tersebut sebenarnya adalah masalah umum. Satu poin utama yang dibuat Ms. Poolet sangat spesifik untuk SQL Server:"Kode toko yang menyentuh data database sebagai prosedur tersimpan".
Ini bagus jika Anda hanya berencana untuk mendukung sistem manajemen database tunggal, seperti SQL Server. Tetapi untuk implementasi portabel, ini bukan saran yang baik. Secara umum, saya merancang portabilitas untuk setidaknya dua sistem manajemen dengan dukungan bahasa prosedur tersimpan yang berbeda. Oleh karena itu, saya akan menghindari praktik ini.
Artikel ini paling berguna untuk orang yang mengembangkan SQL Server dan berfokus pada pasar Amerika (bukan sistem internasional). Namun, sebagai orang Amerika yang tinggal di luar negeri, saya menemukan bahwa beberapa contohnya agak terlalu "berpusat di AS". Misalnya, orang non-Amerika mungkin tidak mengerti apa itu Zip+4 domain adalah dan karena itu tidak akan mengerti mengapa domain ini harus memiliki karakteristik NOT NULL.
Untuk mengilustrasikan ini, saya membuat model data untuk kedua alamat non-Amerika Amerika. Kami akan berasumsi bahwa model data kami mungkin memerlukan entitas untuk ditautkan ke lebih dari satu alamat:misalnya, satu untuk penagihan, satu untuk pengiriman. Alamat pertama akan dikaitkan dengan metode pembayaran; dalam hal ini, alamat tersebut akan digunakan untuk memverifikasi hak Anda untuk mengotorisasi pembayaran tersebut. Alamat pengiriman, tentu saja, adalah tempat pesanan akan dikirimkan.
Mari buat alamat Amerika sebagai bagian dari model database pesanan pelanggan. (Catatan:ini bukan model lengkap, tapi contoh penyimpanan pesanan produk.)
Wise Coders Solutions merekomendasikan untuk mendefinisikan bidang terpisah untuk nomor rumah dan nama jalan dan mengatur bidang ini sebagai NOT NULL; ini akan melarang alamat apa pun yang tidak memiliki nomor rumah dan nama jalan. Tapi bagaimana dengan orang yang menggunakan PO box? Alamat mereka biasanya ditulis sebagai “PO Box 123”. Haruskah kita memaksa mereka untuk menempatkan nomor PO Box sebagai nomor rumah dan "PO Box" sebagai nama jalan? Saya rasa tidak.
Sebagai gantinya, kami akan menggunakan formulir dengan "Baris Alamat 1" dan "Baris Alamat 2". Beberapa orang menentang penggunaan angka dalam nama bidang, tetapi bagi saya ini adalah solusi yang agak jelas. Selain itu, saya telah menentukan panjang bidang maksimum (35 dan 70 karakter) yang umum dalam pembayaran internasional.
Perhatikan bahwa desain AS dan non-AS keduanya memiliki bidang untuk wilayah dalam suatu negara, tetapi desain AS mengharuskan singkatan negara bagian 2 karakter disertakan. Perhatikan juga bahwa desain AS tidak mengizinkan alamat di negara lain.
Jika Anda memiliki kekhawatiran tentang penggunaan global database Anda, Anda perlu berpikir secara global selama fase desain. Apakah database kami siap untuk penggunaan multi-nasional dari aplikasi kami?
Pelajaran dari Desain Data Warehouse yang Buruk
oleh Michelle A. Poolet | SQL Server Pro | 15 Juni 2009
Artikel ini membahas Data Warehouse (DWH) dan beberapa masalah desain dan implementasinya. Ada sedikit fokus pada SQL Server, tetapi ini adalah gambaran umum yang cukup ortodoks dalam merancang pergudangan data dan intelijen bisnis. Memiliki dukungan dan membuat antarmuka yang ramah pengguna mungkin bukan tip yang paling berguna, tetapi saya tidak setuju dengan mereka – saya hanya tidak menganggapnya sebagai bagian dari desain DWH.
Poolet menyatakan bahwa proses extract-transform-load (ETL) harus melakukan pemeriksaan kualitas data dan berpotensi "membersihkan" data sampai ada standar kualitas data yang dapat diterima. Menurut pendapat saya, ini berisiko menciptakan gudang data yang tidak mencerminkan informasi yang diambil dari sistem sumber dengan benar. Pembersihan data harus dilakukan dalam sistem sumber. ETL seharusnya hanya mengubah data sehingga dapat dimuat ke dalam gudang data.
Pada catatan positif, rekomendasi daur ulang atau membuat rutinitas ETL yang dapat digunakan kembali sangat relevan. Selain itu, saya setuju dengan Ms Poolet tentang skalabilitas. Komentarnya tentang manajemen risiko dan kepatuhan, khususnya Sarbanes-Oxley Act, tampaknya cukup spesifik; Saya berasumsi bahwa ini berasal dari bidang bisnisnya.
Akhirnya, dia memiliki daftar periksa yang bagus tentang poin yang berkaitan dengan dimensi, tabel fakta, dan pilihan skema selama desain OLAP (pemrosesan analitik online). Ini tampaknya sangat relevan selama proses desain database. Saya ingin daftar ini lebih panjang, dengan lebih banyak detail atau contoh, tetapi saya senang bahwa tips praktis ini disertakan.
11 Aturan Perancangan Basis Data Penting yang Saya Ikuti
oleh Shivprasad Koirala | Proyek Kode | 25 Februari 2014
Saya sangat menyukai saran yang masuk akal dan jelas di awal artikel ini. Konsep seperti 'mempertimbangkan sifat aplikasi' dan 'memecah data Anda menjadi bagian-bagian logis' sangat tepat. Ini adalah bantuan penting saat membuat model data Anda. Seperti yang dikatakan Mr. Koirala:
Saat Anda memulai desain basis data, hal pertama yang harus dianalisis adalah sifat aplikasi yang Anda rancang, apakah itu Transaksional atau Analitik. Anda akan menemukan banyak pengembang secara default menerapkan aturan normalisasi tanpa memikirkan sifat aplikasi dan kemudian masuk ke masalah kinerja dan penyesuaian.Namun, ada beberapa poin yang membuat saya tidak yakin. Misalnya, ambil pasangan Nama-Nilai terpusat ke dalam satu tabel. Desain One True Lookup Table (OTLT) ini masih diperdebatkan, tetapi umumnya dianggap sebagai praktik yang buruk atau setidaknya anti-pola dalam desain. Saya berpihak pada kelompok anti-OTLT; tabel ini memperkenalkan banyak masalah. Kami mungkin menggunakan analogi pengembangan perangkat lunak menggunakan enumerator tunggal untuk mewakili semua nilai yang mungkin dari semua konstanta yang mungkin setara dengan praktik ini.
Untuk mengingatkan Anda, tabel OTLT biasanya terlihat seperti ini, dengan entri dari beberapa domain dimasukkan ke dalam tabel yang sama. Saya setuju dengan kelompok anti-OTLT; tabel ini menimbulkan banyak masalah.
Selain itu, beberapa poin tampak agak esoteris, seperti "perhatikan data yang dipisahkan oleh pemisah". Meskipun ini adalah poin yang valid, ini bukan poin yang biasanya saya pikirkan saat membuat model data baru.
Mr. Koirala memiliki beberapa item desain OLAP yang umumnya tidak disebutkan dalam daftar praktik terbaik lainnya. Dimasukkannya desain dimensi dan fakta mungkin berguna, tetapi juga bisa berbahaya bagi desainer pemula.
Artikel ini menarik jika Anda beralih dari awal ke pemodelan data yang lebih maju. Ini akan membantu Anda mempertimbangkan sifat analitik versus transaksional dari model masa depan Anda.
Big Data:Lima Tips Kinerja Desain Database Sederhana
oleh Dave Beulke | davebeulke.com | 19 Maret 2013
Artikel Mr. Beulke membahas tip desain yang berfokus pada kinerja. Dia menunjukkan cara memeriksa normalisasi yang tepat:tidak terlalu banyak atau terlalu sedikit. (Overnormalisasi akan berdampak negatif pada kinerja database.)
Selain itu, menggunakan kunci bisnis alami daripada kunci utama yang dihasilkan adalah saran yang baik ketika Anda ingin menghindari menerjemahkan dari kunci bisnis ke ID baris yang dihasilkan untuk setiap akses database.
Menggunakan standar penamaan yang tepat dan jenis kolom juga merupakan saran yang bagus. Poin tentang penggunaan kolom nullable yang berlebihan adalah masuk akal:membuat semua kolom sebagai nullable adalah kesalahan, tetapi mendefinisikan kolom sebagai nullable mungkin diperlukan untuk fungsi bisnis tertentu. Dengan kata-kata penulis sendiri:
Apakah semua kolom NULLable? Dalam definisi kolom database, domain data, rentang, dan nilai yang baik harus dianalisis, dievaluasi, dan dibuat prototipe untuk aplikasi bisnis. Memiliki nilai default yang baik, cakupan nilai yang terbatas dan selalu nilai yang terbaik untuk kinerja dan logika aplikasi. Kolom NULLable hanya bagus ketika data tidak diketahui atau belum memiliki nilai. Data tanggal kematian seseorang adalah contoh klasik dari kolom NULLable karena tidak diketahui kecuali sudah meninggal. Pastikan desain database Anda mewakili data yang diketahui dan hanya menggunakan kolom minimal NULLable.Kiat-kiat Pak Beulke semuanya sangat solid, meskipun agak tidak orisinal. Saya akan menyukai lebih banyak item Big Data – yaitu, bagaimanapun juga, judul artikel. Pada akhirnya, saya merasa artikel itu kurang mendalam dan luas, dan tidak memiliki contoh untuk memperjelas poin-poinnya. Namun, dia memang menawarkan saran berharga terkait normalisasi dan kunci alami.
10 Praktik Terbaik Desain Basis Data
oleh Ann Semua | Aplikasi Perusahaan Hari Ini | 15 Juli 2014
Sepuluh Praktik Terbaik Desain Basis Data sebenarnya disajikan sebagai rangkaian slide. Ms. Semua menyertakan informasi dari pengembang berpengalaman, seperti Michael Blaha. Dia mendorong penggunaan kembali praktik dan pola terbaik Anda. Ini dipahami dan dibuktikan, dan dalam hal itu lebih baik daripada model data yang harus dibuat dari awal. Dari artikel Ms. All:
Sebagai contoh, saya sering merekayasa balik database – database aplikasi yang akan diganti serta database aplikasi terkait. Basis data yang ada ini seringkali tidak memiliki model data yang tersedia. Tetapi model data tersirat dalam skema basis data dan setidaknya dapat diekstraksi sebagian dengan teknik rekayasa balik basis data. … Ada representasi data yang terbukti benar yang sering muncul dan tidak perlu dibuat ulang dari awal.Ini adalah tayangan slide singkat yang dapat dengan cepat dipindai oleh perancang model data dan mendapatkan tip yang sesuai dengan mereka. Bagi saya, tip penggunaan ulang adalah salah satu favorit saya.
Praktik Terbaik Basis Data
oleh Cunningham &Cunningham, Inc.
Praktik terbaik ini dimulai dengan baik, tetapi kemudian mengalami beberapa masalah yang sulit. Saya tidak yakin saran yang ditawarkan selalu tepat.
Sisi positifnya, ada deskripsi yang sangat bagus tentang "praktik terbaik" yang kontroversial seperti selalu menggunakan kunci pengganti yang dibuat secara otomatis dan menggunakan atau menghindari prosedur tersimpan. Sebagai contoh:
Penulis sebelumnya menulis:"Umumnya, hindari PrimaryKeys yang memiliki arti. Nama tidak unik, dan banyak pengidentifikasi yang tampaknya unik seperti nomor Jaminan Sosial sebenarnya tidak, karena masalah keandalan data di dunia nyata." Singkatnya, ini adalah rekomendasi untuk selalu memiliki SurrogateKey yang dibuat secara otomatis (biasanya numerik) alih-alih LogicalKey berbasis domain. Ini adalah jawaban yang agak tepat untuk masalah yang kompleks, meskipun ini adalah jawaban yang cukup dalam beberapa kasus dan setidaknya lebih disukai daripada tidak memiliki PrimaryKey sama sekali.(Catatan Penulis:Saya belum dapat menemukan “penulis sebelumnya” ini saat menelusuri dua kalimat ini di Google.)
Dan tautan ke artikel ringkasan tentang argumen utama di setiap sisi debat Kunci Otomatis versus Kunci Domain disediakan.
Di sisi lain, saya menemukan tip untuk "membagi sistem operasi, data, dan masuk ke disk fisik yang berbeda" dan "menggunakan RAID" agak misterius. Jangan salah paham – ini mungkin saran yang bagus dalam beberapa keadaan, tetapi saya tidak akan memasukkannya ke dalam daftar 20 Teratas saya.
Tips Desain Basis Data
oleh Wise Coders
Ada beberapa tips unik dan menarik dalam koleksi ini, seperti rekomendasi untuk menutup transaksi sesegera mungkin.
Namun, saya tidak sepenuhnya setuju dengan semua tip desain di sini. Misalnya:
Anggap bidang 'Status' dengan nilai 'Aktif', 'Tidak Aktif' dan 'Menganggur'. Anda dapat menyimpan nilai sebagai nama lengkap, tetapi ini bisa menjadi tidak efisien. Menyimpan enumerasi atau char(1) dengan kemungkinan nilai 'a', 'i', 'd', misalnya, akan menggunakan lebih sedikit ruang dalam database.Ini kontroversial, untuk sedikitnya – sumber lain merekomendasikan untuk tidak menggunakan “kode rahasia” seperti ini. Sebagai gantinya, gunakan tabel terpisah untuk menyimpan kode status ini.
Selain itu, statistik yang terkait dengan petunjuk kinerja dipertanyakan, dan tidak ada contoh dalam artikel tersebut.
Sebagai catatan positif, ini adalah daftar pendek tip yang bagus yang harus dapat diakses oleh pemodel database menengah.
Sumber Daya untuk Perancang Basis Data Pemula
Sekarang mari kita periksa beberapa artikel untuk mereka yang baru memulai desain database.
Dasar-dasar Desain Database yang Baik dalam Pengembangan Web
oleh Kayla Knight | Onextrapixel.com | 17 Maret 2011
Di sini kita mendapatkan sedikit lebih maju, dengan saran mulai dari fungsionalitas hingga alat pemodelan.
Ms. Knight memandu kita melalui pengenalan desain database. Artikelnya menarik karena menekankan database untuk pengembangan web. Meski begitu, poinnya cukup universal dan dapat diterapkan pada desain database dalam banyak situasi.
Artikel ini dimulai dengan meminta kita untuk berpikir luas tentang fungsionalitas, bukan hanya database:
Berpikir di luar database. Coba pikirkan tentang apa yang perlu dilakukan situs web. Misalnya, jika situs web keanggotaan diperlukan, insting pertama mungkin mulai memikirkan semua data yang perlu disimpan oleh setiap pengguna. Lupakan saja, itu untuk nanti. Sebaliknya, tuliskan bahwa pengguna dan informasi mereka perlu disimpan dalam database, dan apa lagi? Apa yang perlu dilakukan anggota tersebut di situs? Apakah mereka akan membuat postingan, mengunggah file atau foto, atau mengirim pesan? Kemudian database akan membutuhkan tempat untuk file/foto, posting, dan pesan.Dari sana, Ms. Knight membawa pembaca ke alat desain database dan langkah-langkah yang terlibat dalam prosesnya. Artikelnya memberikan contoh dan tautan ke sumber lain.
Saya pikir artikel ini akan menjadi pengantar yang bagus untuk desainer basis data pemula, dan ini akan bekerja dengan baik dengan Geek Girl seri.
Menjelajahi Tip Desain Basis Data
oleh Doug Lowe | Untuk Boneka
Daftar "Dummies" Mr Lowe adalah serangkaian luas tips desain dasar. Anda dapat menemukan banyak dari ini di tempat lain, tetapi berguna untuk memilikinya di satu tempat. Anda tidak akan menemukan sesuatu yang unik atau sangat kontroversial, kecuali rekomendasi untuk menggunakan prosedur tersimpan. Saya selalu mempertanyakan pernyataan yang kuat ini, karena saya sangat memperhatikan portabilitas model data untuk beberapa sistem DBM.
Berikut adalah salah satu tips yang masuk akal dari Mr. Lowe:
Hindari bidang dengan nama seperti CustomerType, di mana nilai bidang adalah salah satu dari beberapa konstanta yang tidak ditentukan di tempat lain dalam database, seperti R untuk Ritel atau W untuk Grosir. Anda mungkin hanya memiliki dua jenis pelanggan ini hari ini, tetapi kebutuhan aplikasi dapat berubah di masa mendatang, membutuhkan jenis pelanggan ketiga.Rekomendasi ini paling tepat saat bekerja dengan SQL Server.
Lima Tip Desain Basis Data Sederhana
oleh Lamont Adams | TechRepublic | 25 Juni 2001
Kata kunci untuk sumber ini adalah “sederhana”. Anda dapat menemukan informasi ini, dengan lebih banyak penjelasan dan contoh, di artikel lain.
Namun, saran Tuan Adams untuk "Ambil kunci pengguna" adalah poin yang menarik, jarang disebutkan di tempat lain. Dia melanjutkan:
Saat memutuskan bidang atau bidang mana yang akan digunakan sebagai kunci dalam tabel, selalu pertimbangkan bidang yang akan diedit pengguna. Biasanya merupakan ide yang buruk untuk memilih bidang yang dapat diedit pengguna sebagai kunci.Maksud Tuan Adams adalah Anda harus mempertimbangkan potensi kebutuhan pengguna untuk mengedit bidang saat memutuskan bidang mana yang akan digunakan sebagai kunci. Saya ingin penjelasan lebih lanjut mengenai alternatif, seperti kunci sintetis/dihasilkan, tetapi konsepnya bagus.
Saya tidak setuju dengan poin terakhir. Dia merekomendasikan "faktor fudge" untuk setiap tabel yang Anda desain:
Tidak banyak yang lebih buruk daripada menemukan, atau diberi tahu, bahwa database "selesai" Anda kehilangan bidang untuk informasi penting. Di satu perusahaan tempat saya bekerja, ini adalah kejadian umum sehingga kami mulai menyebut "database membeku" sebagai "database slushes."Dalam pikiran saya, ini pada dasarnya adalah "menambahkan beberapa bidang teks tambahan sampai akhir." Hal ini tampaknya bertentangan dengan beberapa tips Mr. Adams lainnya, khususnya yang berkaitan dengan memahami kebutuhan bisnis dan menggunakan nama yang bermakna. Bidang fudge ekstra ini hanya akan disebut sesuatu seperti "ekstra1", atau "ekstra2". Apa kebutuhan bisnis mereka? Dan bagaimana nama-nama yang bermakna ini? Meskipun saya menyukai sebagian besar tip desainnya, "faktor fudge" ini bukanlah sesuatu yang saya patuhi.
Desain Basis Data:Sebutan Terhormat
Jelas, ada artikel lain yang menjelaskan tip desain database dan praktik terbaik. Anda dapat menemukan materi tambahan di tautan berikut:
Desain Basis Data Relasional:Panduan Praktik Terbaik | oleh Digital Ethos | 24 Desember 2012
Praktik Terbaik untuk Desain Skema Basis Data (Pemula) | oleh Jim Murphy | 28 Maret 2011
Praktik Terbaik TI:Desain Basis Data | oleh Universitas Nebraska–Lincoln
Sumber Daya Desain Basis Data Online:Ke Mana Anda Akan Pergi?
Seperti disebutkan, daftar ini jelas tidak dimaksudkan untuk menjadi pemeriksaan menyeluruh dari setiap artikel desain database di Internet. Sebaliknya, kami telah mengidentifikasi beberapa artikel yang menurut kami berguna atau yang memiliki fokus khusus yang mungkin bermanfaat bagi Anda.
Silakan merekomendasikan artikel tambahan.
