Kendala dalam database relasional - Mengapa tidak menghapusnya sepenuhnya?


20

Apakah ada alasan untuk membangun batasan antar tabel (di dalam SQLserver) saat ini? Jika ya, kapan? Sebagian besar aplikasi di daerah saya dibangun berdasarkan prinsip-prinsip objek dan tabel digabungkan sesuai permintaan. Permintaan didasarkan pada kebutuhan dari aplikasi. Saya tidak akan memuat banyak tabel terbatas untuk pencarian sederhana, yang pada gilirannya (setelah tindakan) saling membutuhkan pencarian sederhana.

Alat ORM seperti EntityContext, Linq2Data, NHibernate juga menangani kendala sendiri, setidaknya Anda tahu tabel apa yang saling membutuhkan. Melakukan kendala di dalam server hanya tentang membuat (memaksa) perubahan yang sama dua kali?

Ini biasanya bukan pertanyaan untuk keputusan, tetapi database ini dirancang sangat berbeda. Desainnya terlihat biasa baik, sebagian besar mencerminkan objek yang digunakan oleh aplikasi. Yang mengganggu saya adalah semua kendala dikonfigurasi di dalam SQLserver dengan "not cascade". Yang berarti bahwa Anda harus bermain "mencari dan menemukan" ketika mengkode permintaan basis data baru. Beberapa case membutuhkan hingga 10 level perintah yang tepat untuk membuat satu penghapusan.

Ini mengejutkan saya dan saya tidak yakin bagaimana menanganinya.

Dalam dunia saya yang sederhana, pengaturan itu membuat kendala kehilangan sebagian besar tujuan. OK jika database diakses dari host tanpa pengetahuan desain.

Bagaimana Anda akan bertindak dalam skenario ini?
Mengapa tidak menghapus semua batasan dari db dan menyimpannya di level aplikasi?


6
Anda berencana selalu mengakses data melalui alat ORM tunggal? Atau apakah Anda berencana untuk bersenang-senang mereplikasi semua kendala dengan benar di setiap alat ORM yang digunakan?
Donal Fellows

1
Per komentar terakhir saya kepada Peter saya harus setuju. Titik mengandalkan semua kendala pada basis kode (dan menghapusnya dari db) sangat sempit dan mungkin sepenuhnya berlaku untuk aplikasi yang berumur pendek. Mungkin juga untuk beberapa pengembang / proyek RAD.
Independen

4
Nitpick kecil: Saya pikir ini akan sedikit membingungkan ketika Anda menyebut koneksi kunci asing antara tabel "hubungan". "Relasi" dalam database relasional adalah tabel itu sendiri, bukan koneksi. Terutama ketika kita kemudian berbicara tentang "desain relasional" - apakah itu berarti tabel, atau apakah itu berarti kunci asing?
Thomas Padron-McCarthy

Terima kasih. Saya menyebut "koneksi antar tabel" untuk kendala. Oleh karena itu, Anda benar bahwa saya melihat "database relasional" untuk prinsip-prinsip desain tabel (struktur tabel). Deskripsi yang lebih tepat adalah "pola desain", ketika berhubungan dengan database "hubungan versus objek".
Independen

1
Basis data Anda akan hidup lebih lama dari kode aplikasi Anda. Juga, ORM Anda merusak kinerja aplikasi Anda dan ada kemungkinan Anda akhirnya ingin memotongnya setidaknya dalam kasus penggunaan tertentu. Jika Anda tidak mengetahuinya sekarang, Anda akan mengetahuinya pada akhirnya. samsaffron.com/archive/2011/03/30/… . Selain itu, menghapus semua kendala membuat basis data Anda benar-benar tidak dapat melindungi integritasnya sendiri ketika disalahgunakan oleh aplikasi selain milik Anda, yang bisa berupa apa saja dari aplikasi lain yang sebenarnya hingga eksekutif di ujung lorong dengan Excel.
Craig

Jawaban:


46

Dua alasan umum untuk tidak menghapus hambatan dari DB :

  • Ini dapat diakses oleh lebih banyak aplikasi, sekarang atau di masa depan , yang mungkin atau mungkin tidak menggunakan ORM. Sekalipun pengembang aplikasi tersebut dengan setia menduplikasi semua kendala di sana (yang mungkin secara signifikan lebih sulit menggunakan solusi non-ORM tingkat rendah), itu selalu merupakan pekerjaan ekstra. Dan jika tidak, bahkan satu kelalaian kecil sudah cukup untuk merusak integritas skema ... yang merupakan sesuatu yang Anda tidak ingin mengambil risiko. Di sebagian besar perusahaan, data yang disimpan dalam DB adalah sumber kehidupan bisnis mereka, sehingga integritasnya harus dipastikan dengan cara apa pun. Dan cara terbaik yang dicoba dan terbukti untuk mencapai ini adalah untuk mengimplementasikan sebanyak mungkin kendala dalam DB.
  • Pengoptimal kueri sangat bergantung pada batasan yang diketahui pada tingkat DB. Jika Anda menghapus kendala, kinerja kueri mungkin mulai memburuk . Anda mungkin tidak segera menyadarinya, tetapi suatu hari itu akan memukul Anda, dan pada saat itu mungkin sudah terlambat untuk memperbaikinya dengan mudah. Sifat dari hal-hal ini adalah bahwa kinerja DB cenderung rusak pada waktu beban puncak, ketika ada sedikit kemungkinan untuk melakukan perbaikan desain yang hati-hati dan dipikirkan dengan matang, didukung oleh pengukuran kinerja yang tepat dan analisis terperinci untuk menunjukkan penyebab utama.

Kasing beton Anda terdengar seperti skema DB mungkin awalnya dibuat oleh alat ORM (atau dirancang oleh seseorang yang tidak terlalu berpengalaman dengan dunia relasional), sehingga suboptimal dari sudut pandang relasional. Mungkin lebih baik untuk menganalisis dan memperbaikinya ke arah desain hubungan yang lebih "alami", sambil tetap konsisten dengan pandangan ORM. Mungkin bermanfaat untuk melibatkan pakar DB dalam analisis ini.


5
@Jonas, kemudian berbicara dengan pria itu tentang masalah yang dirasakan dengan desain DB-nya. Berorientasi dan berorientasi objek adalah dua dunia yang berbeda - tidak ada yang merupakan "perbaikan" dari yang lain, dan keduanya memiliki tempat mereka sendiri. Merancang aplikasi C # pada prinsip-prinsip relasional adalah kesalahan besar seperti merancang DB dengan cara OO.
Péter Török

3
@Jonas, yang mencerminkan pembaruan Anda: jika Anda perlu menulis pertanyaan yang terlalu rumit untuk mencapai hal-hal yang tampaknya sederhana terhadap skema DB, itu adalah tanda bahwa desain DB tidak memadai untuk tujuannya - atau bahwa Anda tidak cukup terampil (tolong jangan tersinggung, tidak jelas dari posting Anda seberapa berpengalaman Anda dengan SQL. Sebagai penafian, saya sendiri jauh dari menjadi ahli.)
Péter Török

1
Saya mungkin memiliki beberapa ungkapan untuk dipelajari, untuk membuat diri saya dipahami :). Saya membaca kembali pertanyaan dan jawaban dan harus membalik. Ada titik kuat yang kuat memiliki DB sebagai master untuk semua kendala. Semua sistem perlu dirancang dari itu. Pandangan yang sangat sempit untuk mengatakan bahwa basis kode akan melakukan pekerjaan. Jika setiap sistem dapat memiliki keputusan sendiri tentang kendala, akan berakhir dengan chapparral tinggi dengan hubungan yang salah dan seluruh tabel menjadi yatim. Jika tidak sekarang, maka nanti terjadi dengan coders lain.
Independen

8
"Ini dapat diakses oleh lebih banyak aplikasi, sekarang atau di masa depan." Belum lagi beberapa administrator basis data, menjalankan kueri SQL mentah untuk memperbaiki masalah dengan basis data, sementara pengguna menunggu ...
Thomas Padron-McCarthy

5
+1: jika db menyimpan data bisnis (bukan hanya konfigurasi aplikasi, dll), maka probabilitas bahwa basis data akan keluar langsung / atau diperpanjang di luar aplikasi saat ini mendekati 100%
Binary Worrier

27

Aplikasi dapat datang dan pergi tetapi data hidup selamanya. Di perusahaan saya, DB lebih dari 30-40 tahun, itu akan hidup selama perusahaan itu ada. Aplikasi berubah, pengembang datang dan pergi. Lebih baik memiliki integritas dan model data logis yang baik. Dengan cara itu seseorang dapat melihat data dan mendapatkan pemahaman yang berarti tanpa harus melalui basis kode yang kompleks. Ini juga membantu dalam pelaporan secara signifikan. Juga aplikasi dapat dan akan memiliki bug dan kendala DB adalah penjaga terhadap itu. Posisi default saya adalah memiliki banyak kendala (FK dan periksa) sebanyak mungkin.
Satu-satunya alasan untuk tidak memiliki kendala adalah jika pola desain Anda tidak memungkinkan misalnya Tabel-per-hierarki atau masalah kinerja.


Saya akan mengatakan, Anda melakukan saran yang sangat bijak di sini. Pendapat saya mungkin lebih cocok untuk pengembangan RAD atau apa pun yang berkembang di mana aplikasi memiliki waktu hidup yang singkat - Hanya demi meminimalkan pemeliharaan sambil mengembangkan.
Independen

15

Yang mengganggu saya adalah semua kendala dikonfigurasi di dalam SQLserver dengan "not cascade".

Itu tidak mengganggu saya, itu berarti seseorang telah menunjukkan akal sehat. Penghapusan Cascading seringkali sangat buruk untuk database. Di tempat pertama, kadang-kadang Anda ingin menghapus gagal jika Anda memiliki data di tabel terkait. Misalnya, jika Anda memiliki pelanggan yang memiliki pesanan di masa lalu, Anda tidak ingin dia dihapus atau Anda kehilangan data tentang siapa pesanan itu dan penghapusan kaskade akan menyingkirkan catatan yang akan mengacaukan Anda pelaporan keuangan .

Anda tampaknya berpikir bahwa kemudahan berkembang adalah hal yang paling penting. Dalam dunia basis data, ini tidak benar. Integritas data adalah hal paling kritis pertama diikuti oleh kinerja dan keamanan data. Jika dibutuhkan waktu lebih lama untuk menulis kueri maka jadilah itu.

Basis data biasanya ditindaklanjuti oleh banyak aplikasi = satu situs web atau lebih atau aplikasi desktop, aplikasi pelaporan, layanan web, jendela kueri, proses ETL, dll. Jika Anda tidak menegakkan hambatan pada tingkat basis data, Anda pertama-tama kehilangan integritas data sebagai salah satu aplikasi tersebut mungkin tidak mengikuti semua aturan. Kedua, Anda harus mengkodekan kendala-kendala itu beberapa kali dan menulis ulang jika Anda memutuskan untuk menggunakan aplikasi yang berbeda nanti. Ketiga, Anda tidak dapat mengontrol terlebih dahulu apakah akan perlu melakukan semacam tugas pemeliharaan data yang tidak akan terjadi melalui aplikasi (memperbaiki data dari impor data pelanggan yang buruk misalnya atau mengubah semua 10.000.000 catatan dari satu klien ke klien lain ketika perusahaan dibeli oleh pesaing). Biasanya pengembang aplikasi tidak


Terima kasih atas balasannya. Semua proses dan dan jenis aplikasi yang Anda bicarakan, harus berbicara dengan DAL (yang pada gilirannya akan mengandung kendala). TAPI! Poin Anda sempurna dan komentar Anda baik. Sidenote: Ya. Saya cenderung mencoba cara-cara untuk memudahkan pengembangan. Bagi saya, kompleksitas yang lebih sedikit bisa mengurangi kesalahan. Ini bukan "ingin berkembang lebih mudah / lebih cepat", bahkan jika bisa - jika ditangani dengan salah. Karenanya mengapa saya memposting pertanyaan ini! Saya juga akan melihat akal sehat seseorang jika non-kaskade ini dipilih dengan akal, bukan 100% seperti dalam skenario ini. Saya harus mencari tahu alasannya.
Independen

@Jonas, mungkin ada alasan kinerja juga. Tergantung pada jumlah catatan anak. OK jika Anda menghapus grup kecil tetapi jika jutaan catatan bisa dipicu Anda lebih baik melakukan batch dan tidak mengunci semua tabel sementara seluruh proses terjadi. Secara umum banyak dBA tidak akan mengizinkan penghapusan cascading hanya karena alasan itu karena dapat mengunci sistem prod jika penghapusan mempengaruhi terlalu banyak catatan.
HLGEM

2
Tidak semua proses tidak boleh berbicara dengan DAL. Proses ETL biasanya tidak atau hal-hal yang perlu terjadi di tingkat database yang mempengaruhi banyak catatan ketika beberapa perubahan besar terjadi (seperti klien dibeli). Anda juga tidak dapat melarang siapa pun menggunakan jendela permintaan untuk melakukan perubahan satu kali. Saya belum pernah melihat database yang tidak memaksakan konstelasi pada level database yang tidak memiliki masalah integritas dari waktu ke waktu.
HLGEM

10

Saya pernah membaca suatu tempat yang pada dasarnya mengatakan: Data adalah kunci dari aplikasi Anda . Jika Anda hanya akan PERNAH mengakses data melalui UI Anda (dan maksud saya , seperti sekarang dan selamanya, untuk selamanya ... atau seumur hidup aplikasi Anda, lagi pula) maka Anda tidak perlu kendala basis data. Tetapi ada kemungkinan bahwa sesuatu selain aplikasi itu sendiri perlu menyentuh data, misalnya layanan web, API publik, tugas rake / SQL job / cron / script otomatis, maka Anda akan menyelamatkan diri sendiri dari banyak potensi masalah di jalan dengan menjaga batasan DB.

Saya sangat yakin ini adalah satu bidang pengembangan perangkat lunak di mana Anda seharusnya tidak menerapkan KERING (dan saya sepenuhnya mengharapkan sekumpulan downvotes untuk pernyataan itu). Data Anda adalah jantung dan jiwa dari aplikasi Anda - jika pernah rusak tidak dapat diperbaiki, itu: game over. Sebaiknya IMO untuk menegakkan kendala di mana pun mereka dibutuhkan. Jika itu berarti dalam bentuk Pemicu dan batasan pada tingkat DB, validasi sisi-server pada middleware, dan Javascript sisi-klien pada UI (untuk aplikasi web), maka IMO adalah kejahatan yang diperlukan untuk memastikan data selalu murni .


6

Tahukah Anda apa arti ORM? Pemetaan objek-relasional. Mengutip Wikipedia "teknik untuk mengkonversi data antara sistem tipe yang tidak kompatibel ". Yup, model relasional dan objek tidak cocok satu sama lain. ORM melakukan konversi yang cukup baik, dengan mematuhi aturan kedua sistem tipe. RDBMS diatur sedemikian rupa, sehingga Anda mencapai integritas data dengan menggunakan kendala. Secara umum, integritas adalah hal yang sangat baik untuk dimiliki, sehingga ORM cenderung menggunakannya ketika membuat model data untuk menyimpan data objek. ORM Anda mungkin memiliki alasan yang bagus untuk menggunakan batasan "non cascading". Dan jika ini memaksa Anda untuk membuat pertanyaan yang rumit alih-alih hanya membuat / memperbarui / menjatuhkan objek tertentu, maka ada sesuatu yang salah dengan pengaturan ORM Anda.

Jika Anda menganggap konsep relasional mengganggu, lalu mengapa Anda tidak menggunakan database objek? Beberapa waktu lalu mereka lambat (itulah sebabnya kebanyakan orang masih menggunakan RDBMS) tetapi dari apa yang saya dengar semuanya berubah sedikit. Anda akan menyingkirkan semua nitpicks relasional. Cukup objek masuk, objek keluar.


Topiknya adalah tentang memindahkan fungsionalitas kendala dari DB dan bergantung pada pengaturan / pengembangan dalam basis kode (misalnya .net berbicara: Entity / Linq2Sql).
Independen

Ya saya tahu, tetapi poin saya adalah bahwa Anda harus terlebih dahulu memahami mengapa kendala ada di tempat pertama dan kemudian mengapa mungkin ide yang buruk untuk menjatuhkannya.
Jacek Prucia

Terharu! Tidak dijatuhkan. Saya mengerti Anda menyesali pengetahuan tentang qustion, yang bukan tentang itu.
Independen

Anda tidak dapat memindahkan apa pun di antara sistem yang tidak kompatibel. Anda akan menghilangkan batasan DB, memperkenalkan batasan aplikasi dan hanya berharap mereka akan bekerja sama (yang mungkin ternyata benar dan salah). Ngomong-ngomong, maaf tulus saya jika saya salah paham pertanyaan Anda.
Jacek Prucia

Terima kasih! "Bergerak" berarti "bergerak". Yang berarti Anda membuat batasan aplikasi (ekspresi baik) di setiap sistem. Setidaknya setiap sistem yang tidak dapat berbagi DAL yang sama. Contoh yang sangat bagus adalah permintaan langsung dari admin db yang "memperbaiki sesuatu". Tidak ada kendala db dan kurangnya pengetahuan desain dapat menghasilkan data yatim atau data whorse, benar-benar diejek.
Independen

6

Yah itulah yang dilakukan eBay dan mereka mungkin memiliki salah satu basis data terbesar di dunia:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Terlepas dari apa yang telah dikatakan di atas tentang kinerja yang ditingkatkan oleh integritas referensial, itu sebenarnya dapat terdegradasi; itulah sebabnya database besar telah menjatuhkan batasan mereka dan melakukan pekerjaan di lapisan aplikasi. Dan sejauh yang saya tahu itu adalah satu-satunya alasan yang sangat bagus.

Dengan menjatuhkan batasan-batasan itu Anda pada dasarnya kehilangan jaring pengaman Anda yang menjaga data tetap bersih, dan itu menimbulkan masalah sendiri. Jadi seperti segala sesuatu itu adalah tindakan penyeimbang. Saya kira secara umum menjaga integritas referensial adalah hal yang benar untuk dilakukan.

Setelah bekerja di lingkungan pengembangan dengan integritas referensial yang kuat, saya tahu bahwa dari sudut pandang pengembang, itu bisa sangat menyakitkan; sering dalam lingkungan pengembangan sedikit data kotor tidak masalah dan mencari cara menghapus baris mungkin memakan waktu satu jam atau lebih. Namun, ini juga bisa sangat berguna, karena kendala membuat skema eksplisit.


Akhirnya seseorang yang mengerti saya :-). Anda sepenuhnya benar, keseimbangan adalah poin yang sangat besar di sini. Memindahkan batasan ke level aplikasi mungkin menjadi alternatif yang aman, jika dilakukan sebagai titik strategis. Akan menyenangkan dengan beberapa URL ke situs yang terbukti menurunkan kinerja karena kendala / integritas yang kuat.
Independen

10
Ya dan jangan lupa - jangan lupa - bahwa Ebay, seperti Facebook dan Amazon - adalah trilyun kali lebih besar dari 99,99% dari basis data, dan apa yang baik untuk mereka mungkin sangat berbeda dari apa yang baik untuk database Anda.
Tony Andrews

2
Dan ebay, Facebook, Amazon mungkin tidak menggunakan basis data tanpa kendala untuk perangkat lunak keuangan dan akuntansi mereka atau perangkat lunak inventaris mereka atau data SDM mereka atau di mana pun di mana data tidak hilang sangat penting.
HLGEM

2
Jika Anda memiliki cukup waktu, keahlian, dan uang, pada akhirnya Anda dapat memprogram RDBMS, server web, atau sistem operasi apa pun untuk memenuhi kebutuhan tertentu.
JeffO

1
eBay tidak melakukan itu sampai volume data yang mereka hadapi pada dasarnya melampaui kemampuan server database untuk mengatasinya, dan mereka memiliki jutaan untuk berinvestasi dalam arsitektur baru mereka. Jika Anda melakukan transaksi milyaran sehari, maka tentu saja bekerja keras tentang menghilangkan kendala dan pergi ke sistem yang benar-benar berbasis antrian, tanpa transaksi, dan dapat diskalakan seperti eBay. Jika tidak, jangan meremehkan server basis data Anda, dan jangan biarkan basis data Anda mengalami kerusakan data dengan menghapus semua kendala Anda.
Craig

4

Pertama - jawaban saya: Tidak, Anda tidak harus bergantung pada aplikasi sendirian untuk menjaga data Anda.

Ini menunjuk pada perdebatan yang lebih besar: ORM telah mendorong budaya penghinaan untuk interaksi DB "langsung", seringkali dengan mengorbankan normalisasi / integritas referensial. Tabel secara paksa dipetakan ke hierarki objek yang sewenang-wenang, dengan mengorbankan desain yang tersirat dalam model relasional. Decoupling yang disukai oleh OOP bisa dikorbankan di sini karena aplikasi membuat desainnya terasa dalam struktur data. Sementara ORM telah menunjukkan utilitas yang luar biasa, ORM tampaknya didasarkan pada penyalahgunaan atau ketidakpercayaan SQL.

Paradigma baru muncul (kembali), ambil contoh pemrograman Fungsional. Jika tim dev memutuskan untuk merangkul metodologi pemrograman baru maka implikasi apa yang akan terjadi pada data yang telah terstruktur sesuai dengan persyaratan ORM?

Saya setuju dengan @ Jacek Prucia - Saya pikir ORM cocok untuk RDBMS, saya pribadi akan memilih DBAL di RDBMS, atau menggunakan OODB dengan ORM.


+1 untuk berbicara alternatif dari topik. Sisi lain dari perdebatan ini tentu saja: "Seberapa burukkah beberapa data?" dan jawabannya bisa berupa pembatalan atau miliaran pemasukan uang ke rekening bank orang lain. Serta beberapa data yatim yang dihapus dengan rutinitas pembersihan yang baik. Ringkasan topik ini, terlihat seperti konsistensi terhadap biaya fleksibilitas. Yang pada gilirannya sepenuhnya tergantung pada tingkat keparahan konten dan penggunaan db.
Independen

3

Kendala adalah satu-satunya jaminan Anda bahwa Anda memiliki konsistensi dan integritas data di tingkat basis data. Tentu, Anda dapat menegakkan batasan menggunakan kode aplikasi Anda, tetapi bagaimana jika, di masa depan, Anda perlu memodifikasi data secara langsung? Anda mungkin mengerti bagaimana menjaga integritas data, tetapi orang lain mungkin tidak. Menjaga kendala pada tingkat data memastikan bahwa integritas dipastikan bahkan ketika seseorang berkeliaran di tempat-tempat yang tidak mereka pahami.

Lebih jauh, katakanlah aplikasi Anda perlu ditulis ulang, tetapi dengan database yang sama. Semua kendala dalam kode hanya meminta bug yang mencegah beberapa entri sementara memungkinkan data yang salah.

Saat berkembang, jagalah agar tetap sederhana. Kendala memungkinkan Anda melakukan itu. (Yang mengatakan, ketika kendala melempar kesalahan, jangan meludah kesalahan yang sama kembali ke pengguna. Buat kesalahan dimengerti.)

(Mengenai masalah kaskade: itu adalah hal yang baik. Saya lebih suka untuk melemparkan kesalahan bahwa beberapa catatan lain harus dihapus terlebih dahulu, daripada mengandalkan kaskade untuk mendapatkan segalanya dengan benar. Cascade bagus secara teori, tetapi tidak harus selalu jadi dalam praktek.)


2

Salah satu masalah dengan kendala dalam database adalah mereka memberikan informasi terbatas pada program tentang apa yang gagal dan bagaimana cara memperbaikinya. Ini berarti bahwa, untuk penanganan yang lancar, seringkali perlu untuk mengulang pemeriksaan kendala dalam aplikasi, dan oleh karena itu pemeriksaan kendala basis data merupakan usaha yang sia-sia.

Ini berisiko membahayakan integritas data, jadi kami punya untung di sini. Untuk data penting, memastikan integritas data hampir selalu lebih penting daripada kinerja, dan jauh lebih baik untuk gagal transaksi bahkan jika itu terlihat sewenang-wenang daripada mengacaukan data.

Untuk menghapus kendala dengan aman, maka penting untuk mengamankan akses basis data sehingga tidak ada yang dapat mengubah basis data tanpa memeriksa kendala. Ini tidak dapat diandalkan ketika menulis aplikasi baru atau mencari cara ad hoc untuk menangani data, karena yang diperlukan hanyalah satu kesalahan dan database rusak.

Oleh karena itu, untuk menghilangkan kendala basis data, perlu untuk menetapkan apa yang dapat dan apa yang tidak dapat dilakukan dengan basis data di muka, sehingga semua aplikasi dapat ditulis, ditinjau, dan diuji secara luas. Semua persyaratan basis data harus ditetapkan di muka, dan setiap perubahan pada persyaratan basis data akan membutuhkan pekerjaan yang luas. Ini adalah sesuatu dari metodologi air terjun beku, yang hanya berfungsi dalam kasus yang sangat spesifik. (Mendesain, mengimplementasikan, dan memelihara persyaratan seperti berjalan di atas air. Sesuatu harus dibekukan terlebih dahulu, dan jika tidak dibekukan cukup hasilnya dapat menjadi bencana.)

Salah satu kasus di mana ia berfungsi adalah aplikasi perusahaan besar seperti PeopleSoft dan SAP, di mana aplikasi sudah melakukan segalanya, dan ada cara yang ditentukan dengan hati-hati untuk memperluasnya. Ada kemungkinan lain yang sangat jarang.

Jadi, kecuali Anda bekerja pada proyek perusahaan yang sangat besar (dan saya tidak mau) atau dapat berjalan di atas air cair, tinggalkan kendala itu dalam database.


1
Terima kasih atas balasannya. Kendala akan ada di db untuk proyek ini! Saya sepenuhnya yakin :). Saya juga akan memiliki mata yang lebih luas ketika memutuskan ini pada proyek masa depan dan dalam diskusi dengan bagian lain.
Independen

1
Juga pertimbangkan bahwa tanpa kendala, Anda menyerahkannya ke kode aplikasi itu sendiri untuk mendeteksi bahwa itu kacau. Itu kode aplikasi yang sama yang melanggar kendala dalam contoh Anda, omong-omong, kendala yang menyelamatkan database Anda dari inkonsistensi data atau korupsi. Menggunakan kendala tidak secara otomatis berarti kinerja yang lebih rendah juga, dan tidak menggunakan kendala membuat database Anda terbuka sehingga tidak dapat melindungi dirinya sendiri.
Craig
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.