Mengapa kunci harus dibuat eksplisit?

15

Saya sangat baru dengan subjek database jadi ini mungkin terdengar bodoh, tapi saya ingin tahu mengapa kunci harus dibuat eksplisit dalam sebuah tabel. Apakah ini terutama untuk memberi tahu pengguna bahwa nilai kolom yang diberikan (semoga) dijamin unik di setiap baris? Keunikannya harus tetap ada meskipun tidak disebutkan.

primary-key unique-constraint

— dsaxton
sumber

Apakah maksud Anda jika Anda memiliki kunci UNIK, mengapa repot-repot memiliki kunci PRIMER?

— Vérace

1

Kenapa mereka diumumkan? Tampaknya sangat membantu, tetapi apakah sebenarnya perlu memiliki database yang berfungsi?

— dsaxton

1

Mereka tidak diperlukan untuk database Anda untuk bekerja tetapi mereka diperlukan untuk data Anda untuk "bekerja" yaitu konsisten, karena itulah cara Anda memberitahu server database Anda untuk menjaga informasi yang konsisten.

— Andriy M

Jika database tahu bahwa bidang yang diberikan adalah kunci, efek sampingnya adalah ia dapat membantu Anda menemukan baris yang berisi kunci jauh lebih cepat daripada jika perlu melihat semua baris dalam tabel. Indeks adalah bagian yang sangat penting mengapa basis data berguna.

— Thorbjørn Ravn Andersen

32

Anda jelas menyarankan bahwa CONSTRAINTs di dalam basis data harus diberlakukan oleh aplikasi yang mengakses basis data itu?

Ada banyak alasan mengapa ini adalah ide yang buruk (buruk, buruk ...).

1) Jika Anda sedang membangun "roll-your-own" engine "engine" (yaitu dalam kode aplikasi Anda), maka Anda hanya meniru apa yang Oracle / SQL Server / MySQL / PostgreSQL / <. Siapa pun ...> telah menghabiskan tahun menulis. Kode CONSTRAINT mereka telah diuji selama bertahun-tahun oleh jutaan pengguna akhir.

2) Dengan segala hormat kepada Anda dan tim Anda, Anda tidak akan memperbaikinya bahkan dalam hitungan tahun - dari sini , kode MySQL saja menelan biaya 40 Juta dolar. Dan MySQL adalah yang termurah dari 3 server di atas, dan mereka bahkan tidak mengimplementasikan CHECK CONSTRAINTs. Jelas, mendapatkan RI (Integritas Referensial) sepenuhnya benar itu sulit.

Saya sering mengunjungi forum Oracle dan saya tidak bisa memberi tahu Anda berapa kali manajer / programmer yang buruk memiliki proyek yang disodorkan kepadanya di mana si jenius yang memiliki pekerjaannya sebelumnya memiliki ide "cemerlang" untuk melakukan apa yang Anda sarankan .

Jonathan Lewis (dia menulis buku setebal 550 halaman tentang dasar-dasar optimiser Oracle ) memberi sebagai tidak. 2 dari Bencana Desain di buku lain (" Tales of the Oak Table " - the Oak Table adalah sekelompok ahli Oracle) adalah

Kami akan memeriksa integritas data di tingkat aplikasi alih-alih memanfaatkan kemampuan pengecekan kendala Oracle.

3) Bahkan jika dengan beberapa keajaiban Anda dapat menerapkan RI dengan benar, Anda harus sepenuhnya mengimplementasikannya berulang kali untuk setiap aplikasi yang menyentuh database itu - dan jika data Anda penting, maka aplikasi baru akan melakukannya. Memilih ini sebagai sebuah paradigma akan membawa Anda dan rekan programmer Anda (belum lagi staf pendukung dan penjualan) ke kehidupan yang terus-menerus memadamkan api dan kesengsaraan.

Anda dapat membaca lebih lanjut tentang mengapa menerapkan data CONSTRAINT pada tingkat aplikasi tidak kurang gila di sini , di sini dan di sini .

Untuk secara khusus menjawab pertanyaan Anda:

Kenapa mereka diumumkan? Tampaknya sangat membantu, tetapi apakah sebenarnya perlu memiliki database yang berfungsi

Alasan bahwa KEYs (baik PRIMARY, FOREIGN, UNIQUEatau hanya biasa INDEXes) dinyatakan adalah bahwa, sementara itu tidak benar-benar diperlukan untuk database untuk memiliki mereka untuk itu berfungsi, itu benar-benar diperlukan bagi mereka untuk dinyatakan untuk itu untuk fungsi dengan baik .

— Vérace
sumber

1

Terima kasih atas jawaban anda. Saya mungkin perlu belajar lebih banyak untuk memahaminya sepenuhnya. (Saya sebenarnya bukan anggota tim, saya hanya belajar tentang basis data karena penasaran.)

— dsaxton

2

Baca beberapa buku (Date, Garcia-Molina ...) dan kembalilah kepada kami jika Anda memiliki pertanyaan spesifik (pertanyaan yang terlalu luas dianggap di luar topik di sini). ps Selamat datang di forum :-)

— Vérace

Meskipun saya tidak akan pernah menyarankan agar Anda tidak menempatkan kendala dalam database (Anda harus selalu memiliki kunci primer dan kunci asing minimal), Anda dapat menghindari # 3 dengan meminta semua aplikasi menggunakan layanan bersama (arsitektur berorientasi layanan) ). (Bagaimanapun, itu mungkin sesuatu yang harus Anda pertimbangkan untuk banyak konsumen, karena melakukan setiap pemeriksaan integritas terakhir yang Anda butuhkan dalam basis data juga dapat menjadi mimpi buruk. Pikirkan pemicu di mana-mana membuat cek di seluruh tabel dan baris sepanjang waktu.)

— jpmc26

10

Saat Anda membuat kunci dalam database, mesin DBMS memberlakukan batasan keunikan pada atribut kunci. Ini melayani setidaknya tiga tujuan terkait:

Integritas data: data duplikat tidak dapat dimasukkan ke dalam atribut kunci. Karena itu, setiap dependensi pada tombol dijamin.
Identifikasi: pengguna dapat mengandalkan kunci sebagai cara mengidentifikasi dan memperbarui data secara akurat.
Pengoptimalan: informasi (metadata) tentang atribut mana yang unik tersedia untuk pengoptimal permintaan DBMS. Informasi ini memungkinkan pengoptimal untuk menyederhanakan eksekusi kueri dengan cara tertentu sehingga kueri akan mengeksekusi lebih cepat.

— nvogel
sumber

8

Saya akan menambahkan satu aspek ke jawaban luar biasa yang ada: Dokumentasi. Seringkali penting untuk melihat jenis kunci apa yang dapat Anda gunakan untuk mengidentifikasi suatu entitas. Kombinasi kolom unik apa pun adalah kunci kandidat.

Kunci utama cenderung menjadi konsep yang sangat berguna dalam praktik.

Apakah Anda menerapkan kunci atau tidak (Anda mungkin harus) dokumentasi itu berharga dalam dirinya sendiri.

— boot4life
sumber

1

Diagram database! Hal pertama yang selalu saya lakukan ketika diminta untuk mengatakan sesuatu yang bermakna tentang perangkat lunak yang tidak saya kenal adalah melihat apakah ia menggunakan basis data relasional, dan jika ya, cobalah membuat diagram basis data. Itu akan memberi saya ide bagus tentang informasi yang bekerja dengan aplikasi. Sayangnya, 90% dari database yang saya lihat tidak mendeklarasikan kunci asing, jadi diagramnya hanya set tabel. Mendedikasikan kunci asing tingkat aplikasi implisit membutuhkan tebakan dan penyesuaian.

— reinierpost

1

@reinierpost Saya sepenuhnya setuju. Data adalah objek yang paling berharga untuk didokumentasikan dan tetap bersih karena tetap ada selamanya. Kode dapat berubah; itu cenderung lebih sementara.

— boot4life

@reinierpost - Berkonsultasi untuk sebuah perusahaan yang menyediakan perangkat lunak untuk seluruh infrastruktur kereta api di sebuah negara besar di Eropa (besar - pikirkan miliaran widget) dan saya berkata, "Aduh, saya hanya akan menjalankan kueri untuk memeriksa FOREIGN KEYdefinisi untuk mendapatkan rasakan untuk sistem ". Permintaan saya mengembalikan zip !!! Yakin bahwa SQL saya salah, saya menyebutkan ini ke salah satu programmer senior. Dengan bangga (tidak kurang) dia mengumumkan (seolah-olah dia sedang menghadirkan putra yang baru lahir) bahwa sistem tidak memiliki FK karena "semua pencarian sedang dilakukan PRIMARY KEY" - (tidak relevan). <Doh ...> ala Homer Simpson!

— Vérace

5

Alasan lain mengapa Anda harus menggunakan CONSTRAINTs alih-alih beberapa kode aplikasi-dalam:

Apa yang terjadi jika pengembang / dba menggunakan pernyataan insert / update / delete untuk mengubah data secara langsung dalam DB? Dalam hal ini semua integritas referensial berbasis aplikasi yang bagus Anda tidak akan berguna. Saya tahu, beberapa pengembang menyukai kemungkinan untuk mengubah data secara langsung tanpa harus repot dengan RI karena mereka tahu apa yang mereka lakukan - setidaknya yang paling banyak waktu (tetapi tidak selalu)

PS: Tentu saja Anda bisa membuat pemicu, tetapi biasanya lambat sekali (dibandingkan dengan CONSTRAINTS).

— Thomas Franz
sumber