Pola Desain Basis Data Relasional? [Tutup]

283

Pola desain biasanya terkait dengan desain berorientasi objek.
Apakah ada pola desain untuk membuat dan memprogram basis data relasional ?
Banyak masalah pasti harus memiliki solusi yang dapat digunakan kembali.

Contoh akan mencakup pola untuk desain tabel, prosedur tersimpan, pemicu, dll ...

Apakah ada repositori online dari pola semacam itu, mirip dengan martinfowler.com ?

Contoh masalah yang bisa dipecahkan oleh pola:

Menyimpan data hierarkis (misalnya tabel tunggal dengan tipe vs beberapa tabel dengan kunci 1: 1 dan perbedaan ...)
Menyimpan data dengan struktur variabel (mis. Kolom generik vs kolom xml vs dibatasi ...)
Mendenormalkan data (bagaimana melakukannya dengan dampak minimal, dll ...)

design-patterns database-design rdbms

— Sklivvz
sumber

Saya akan mengajukan Q&A terbaik di sini untuk penyimpanan data hierarkis: stackoverflow.com/questions/4048151/…

— orangepips

1

Menurut panduan di-topik kami , " Beberapa pertanyaan masih di luar topik, bahkan jika mereka masuk ke dalam salah satu kategori yang tercantum di atas: ... Pertanyaan yang meminta kami untuk merekomendasikan atau menemukan buku, alat, pustaka perangkat lunak, tutorial atau lainnya sumber di luar situs di luar topik ... "

— Robert Columbia

@RobertColumbia pertanyaannya adalah pada topik 2008, ketika ditanya ...

— Sklivvz

Lihatlah daftar sumber daya pola desain ini pada basis data relasional dan banyak bidang rekayasa perangkat lunak github.com/DovAmir/awesome-design-patterns

— dov.amir

150

Ada sebuah buku di Martin Fowler's Signature Series yang disebut Refactoring Databases . Itu memberikan daftar teknik untuk refactoring database. Saya tidak bisa mengatakan saya sudah sering mendengar daftar pola basis data.

Saya juga sangat merekomendasikan Pola Model Data David C. Hay dan tindak lanjut A Metadata Map yang dibangun berdasarkan yang pertama dan jauh lebih ambisius dan menarik. Pendahuluan saja yang mencerahkan.

Juga tempat yang tepat untuk mencari beberapa model database pra-kalengan adalah Len Model Buku Sumber Daya Seri Silverston Volume 1 berisi model data yang berlaku secara universal (karyawan, akun, pengiriman, pembelian, dll), Volume 2 berisi model data spesifik industri (akuntansi, layanan kesehatan, dll), Volume 3 menyediakan pola model data.

Akhirnya, sementara buku ini seolah-olah tentang UML dan Object Modeling, Peter Coad's Modeling in Color With UML memberikan proses yang didorong oleh "pola dasar" pemodelan entitas mulai dari premis bahwa ada 4 arketipe inti dari setiap objek / model data

— Michael Brown
sumber

1

Buku ini berjudul [Database Refactoring: Desain Basis Data Evolusi] [1] oleh Scott W. Ambler dan Pramod J. Sadalage dan memang sangat bagus. [1]: ambysoft.com/books/refactoringDatabases.html

— Panos

3

Mengenai buku Ambler: Tidak, Anda tidak bisa mencantumkan "menyisipkan kolom" atau "membuat batasan FK" sebagai pola karena alasan yang sama. Buku Gang 4 tidak mencantumkan loop "untuk" sebagai sebuah pola.

— Tegiri Nenashi

Itu bukan pola itu adalah refactoring. Suka metode ekstrak, atau ganti nama parameter. Refactoring dan pola berjalan beriringan.

— Michael Brown

Satu untuk menambahkan: "Pola Analisis" oleh Fowler. Mirip dengan barang

— Neil McGuigan

2

Volume 3 Len Silverston adalah satu-satunya yang saya anggap sebagai "Pola Desain." 2 pertama menunjukkan model data sampel yang umum dalam kerangka waktu buku ditulis. Volume 3 meskipun sebenarnya memiliki beberapa pola desain untuk skenario masalah yang diberikan. Misalnya, bab 4 mencakup hierarki / agregasi / skenario peer-to-peer, dan kemudian menawarkan beberapa desain yang membahas masing-masing dengan pro dan kontra masing-masing.

— DarrellNorton

46

Pola desain bukan solusi yang dapat digunakan kembali.

Pola desain dapat digunakan kembali, menurut definisi. Mereka adalah pola kamu deteksi dalam solusi bagus lainnya.

Suatu pola tidak dapat digunakan kembali secara sepele. Anda dapat menerapkan desain down Anda dengan mengikuti pola.

Patters desain relasional meliputi hal-hal seperti:

Hubungan satu ke banyak (detail utama, orangtua-anak) menggunakan kunci asing.
Hubungan Many-to-Many dengan tabel jembatan.
Hubungan satu-ke-satu opsional dikelola dengan NULL di kolom FK.
Skema Bintang: Dimensi dan Fakta, desain OLAP.
Desain OLTP sepenuhnya dinormalisasi.
Beberapa kolom pencarian yang diindeks dalam dimensi.
"Tabel pencarian" yang berisi PK, deskripsi, dan nilai kode yang digunakan oleh satu atau lebih aplikasi. Mengapa punya kode? Saya tidak tahu, tetapi ketika harus digunakan, ini adalah cara untuk mengelola kode.
Uni-table. [Beberapa menyebut ini sebagai anti-pola; itu sebuah pola, kadang-kadang itu buruk, kadang-kadang itu bagus.] Ini adalah tabel dengan banyak hal yang sudah bergabung yang melanggar bentuk normal kedua dan ketiga.
Tabel array Ini adalah tabel yang melanggar bentuk normal pertama dengan memiliki array atau urutan nilai dalam kolom.
Basis data penggunaan campuran. Ini adalah database yang dinormalisasi untuk pemrosesan transaksi tetapi dengan banyak indeks tambahan untuk pelaporan dan analisis. Ini anti-pola - jangan lakukan ini. Orang-orang tetap melakukannya, jadi ini masih sebuah pola.

Kebanyakan orang yang mendesain database dapat dengan mudah mengoceh setengah lusin "Ini salah satu dari mereka"; ini adalah pola desain yang mereka gunakan secara teratur.

Dan ini tidak termasuk pola administrasi dan operasional penggunaan dan manajemen.

— S.Lott
sumber

Beberapa pola lain yang pernah saya lihat adalah tabel anak multi-orangtua (yaitu, seperti catatan global dengan tipe objek dan objekid yang dapat menautkan ke tabel lain), atau FK referensial diri (yaitu, karyawan.kurus -> karyawan. Indo). Saya juga telah menggunakan tabel konfigurasi singleton yang memiliki banyak kolom.

— r00fus

1

Mengapa tepatnya database penggunaan campuran merupakan anti-pola. Apa yang harus saya lakukan jika saya ingin menarik laporan dari database?

— zaitun

3

@lhnz: Anda tidak dapat menarik banyak dari besar laporan dari desain database transaksional - mengunci untuk pelaporan akan memperlambat transaksi. Gabungan kompleks (dilakukan berulang-ulang) adalah satu ketukan lain terhadap kinerja transaksi. Anda tidak dapat melakukan keduanya dalam satu basis data. Untuk melakukan banyak laporan besar, Anda harus memindahkan data ke skema bintang. Pola skema bintang dioptimalkan untuk pelaporan. Dan memindahkan data menghilangkan pertengkaran kunci.

— S.Lott

Apakah normalisasi skema akan mengurangi pertikaian kunci baris jika Anda membuat tabel menyimpan lebih banyak data "kohesif"? Pemikiran saya adalah bahwa jika sebuah meja besar sedang melayani penulisan untuk 2 jenis set data tetapi keduanya berada di baris yang sama, ini akan menghasilkan pertikaian kunci yang tidak perlu.

— CMCDragonkai

6

AskTom mungkin adalah satu-satunya sumber daya yang paling membantu tentang praktik terbaik pada Oracle DBs. (Saya biasanya cukup mengetik "asktom" sebagai kata pertama dari kueri google pada topik tertentu)

Saya tidak berpikir itu benar-benar tepat untuk berbicara tentang pola desain dengan basis data relasional. Database relasional sudah merupakan penerapan "pola desain" untuk suatu masalah (masalahnya adalah "bagaimana merepresentasikan, menyimpan, dan bekerja dengan data dengan tetap menjaga integritasnya", dan desain menjadi model relasional). Pendekatan lain (umumnya dianggap usang) adalah model Navigational dan Hierarchical (dan saya masih memiliki banyak model lain).

Karena itu, Anda dapat mempertimbangkan "Pergudangan Data" sebagai "pola" atau pendekatan yang agak terpisah dalam desain basis data. Secara khusus, Anda mungkin tertarik membaca tentang skema Bintang .

— Galghamon
sumber

4

Setelah bertahun-tahun pengembangan basis data saya dapat mengatakan ada beberapa jalan keluar dan beberapa pertanyaan yang harus Anda jawab sebelum Anda mulai:

pertanyaan:

Apakah Anda ingin menggunakan DBMS lain di masa depan? Jika ya maka tidak digunakan untuk hal-hal SQL khusus dari DBMS saat ini. Hapus logika dalam aplikasi Anda.

Tidak menggunakan:

spasi putih dalam nama tabel dan nama kolom
Non Ascii karakter dalam nama tabel dan kolom
mengikat ke huruf kecil atau huruf besar tertentu. Dan jangan pernah menggunakan 2 tabel atau kolom yang berbeda hanya dengan huruf kecil dan huruf besar.
tidak menggunakan kata kunci SQL untuk nama tabel atau kolom seperti "FROM", "BETWEEN", "DELETE", dll

rekomendasi:

Gunakan NVARCHAR atau setara untuk dukungan unicode maka Anda tidak memiliki masalah dengan codepages.
Beri setiap kolom nama unik. Ini membuatnya lebih mudah saat bergabung untuk memilih kolom. Sangat sulit jika setiap tabel memiliki kolom "ID" atau "Nama" atau "Deskripsi". Gunakan XyzID dan AbcID.
Gunakan bundel sumber daya atau sama dengan untuk ekspresi SQL yang kompleks. Itu membuatnya lebih mudah untuk beralih ke DBMS lain.
Tidak menggunakan tipe data apa pun. DBMS lain tidak dapat memiliki tipe data ini. Sebagai contoh, Oracle daes tidak memiliki nomor SMALLINT saja.

Saya harap ini adalah titik awal yang baik.

— Horcrux7
sumber

7

Meskipun komentar Anda cukup instruktif dan bermanfaat, mereka bukan pola desain. Itu adalah praktik terbaik. Terima kasih,

— Sklivvz

7

Saya tidak setuju dengan rekomendasi untuk nama kolom yang unik. Saya lebih suka mengatakan customer.id untuk ambigu daripada mengatakan customerid bahkan di mana tidak ada yang ambigu.

— Paul Tomblin

1

Pertanyaan Anda agak kabur, tapi saya kira UPSERTbisa dianggap sebagai pola desain. Untuk bahasa yang tidak diimplementasikan MERGE, sejumlah alternatif untuk menyelesaikan masalah (jika ada baris yang sesuai, ada yang UPDATElain INSERT).

— Sören Kuklau
sumber

UPSERT adalah perintah dan bagian dari bahasa SQL. Itu bukan sebuah pola.

— Todd R

UPSERT adalah perintah dalam beberapa varian bahasa SQL - sejumlah platform tidak memilikinya, atau baru saja mendapatkannya.

— Steve Homer

@ToddR - Saya pernah mendengar mengatakan (sedikit sinis) bahwa "pola" benar-benar tidak lebih dari kekurangan dalam suatu bahasa atau model, bahwa pengguna harus membuat work-arounds for. Saya tidak tahu apa yang dilakukan UPSERT, tetapi sementara itu telah ditambahkan ke beberapa SQL dan bukan yang lain, itu adalah sebuah pola.

— Martin F

1

Tergantung apa yang Anda maksud dengan suatu pola. Jika Anda berpikir Orang / Perusahaan / Transaksi / Produk dan semacamnya, maka ya - ada banyak skema basis data generik yang sudah tersedia.

Jika Anda berpikir Factory, Singleton ... maka tidak - Anda tidak memerlukan semua ini karena mereka terlalu rendah untuk pemrograman DB.

Jika Anda berpikir penamaan objek database, maka itu di bawah kategori konvensi, bukan desain per se.

BTW, S.Lott, hubungan satu-ke-banyak dan banyak-ke-banyak bukanlah "pola". Mereka adalah blok bangunan dasar dari model relasional.

— Andrew bukan Orang Suci
sumber

bagaimana dengan pewarisan basis data seperti (orang, pelanggan, karyawan) mungkin hal semacam itu dapat dianggap sebagai pola desain?

— Muflix