Apa yang terjadi dengan kendala basis data?


46

Ketika saya meninjau model database untuk RDBMS, saya biasanya terkejut menemukan sedikit atau tidak ada kendala (selain PK / FK). Misalnya, persentase sering disimpan dalam kolom tipe int(sementara tinyintakan lebih tepat) dan tidak ada CHECKkendala untuk membatasi nilai ke kisaran 0,100. Demikian pula pada SE.SE, jawaban yang menyarankan kendala pemeriksaan sering menerima komentar yang menunjukkan bahwa database adalah tempat yang salah untuk kendala.

Ketika saya bertanya tentang keputusan untuk tidak menerapkan kendala, anggota tim merespons:

  • Entah mereka bahkan tidak tahu bahwa fitur seperti itu ada di database favorit mereka. Dapat dimengerti dari pemrogram yang hanya menggunakan ORM, tetapi jauh lebih sedikit dari DBA yang mengklaim memiliki pengalaman 5+ tahun dengan RDBMS yang diberikan.

  • Atau bahwa mereka menegakkan batasan seperti itu di tingkat aplikasi, dan menduplikasi aturan-aturan itu dalam database bukanlah ide yang baik, melanggar SSOT.

Baru-baru ini, saya melihat semakin banyak proyek di mana bahkan kunci asing tidak digunakan. Demikian pula, saya telah melihat beberapa komentar di sini di SE.SE yang menunjukkan bahwa pengguna tidak terlalu peduli dengan integritas referensial, membiarkan aplikasi menanganinya.

Ketika bertanya kepada tim tentang pilihan untuk tidak menggunakan FK, mereka mengatakan bahwa:

  • Ini PITA, misalnya ketika seseorang harus menghapus elemen yang direferensikan di tabel lain.

  • Batu NoSQL, dan tidak ada kunci asing di sana. Karena itu, kami tidak membutuhkannya di RDBMS.

  • Ini bukan masalah besar dalam hal kinerja (konteksnya biasanya aplikasi web intranet kecil yang bekerja pada set data kecil, jadi memang, bahkan indeks tidak akan terlalu penting; tidak ada yang akan peduli jika kinerja permintaan yang diberikan melewati 1,5 dtk . hingga 20 ms.)

Ketika saya melihat aplikasi itu sendiri, saya secara sistematis melihat dua pola:

  • Aplikasi membersihkan data dengan benar dan memeriksanya sebelum mengirimnya ke database. Misalnya, tidak ada cara untuk menyimpan nilai 102sebagai persentase melalui aplikasi.

  • Aplikasi ini mengasumsikan bahwa semua data yang berasal dari basis data benar-benar valid. Artinya, jika 102datang sebagai persentase, entah sesuatu, suatu tempat akan macet, atau itu hanya akan ditampilkan sebagaimana adanya kepada pengguna, yang mengarah ke situasi aneh.

  • Sementara lebih dari 99% kueri dilakukan oleh satu aplikasi, seiring waktu, skrip mulai muncul — skrip dijalankan dengan tangan saat dibutuhkan, atau pekerjaan cron. Beberapa operasi data juga dilakukan dengan tangan pada database itu sendiri. Skrip dan kueri SQL manual memiliki risiko tinggi untuk memasukkan nilai yang tidak valid.

Dan inilah pertanyaan saya:

Apa alasan untuk memodelkan basis data relasional tanpa kendala pemeriksaan dan akhirnya bahkan tanpa kunci asing?


Untuk apa nilainya, pertanyaan ini dan jawaban yang saya terima (terutama diskusi yang menarik dengan Thomas Kilian) mendorong saya untuk menulis artikel dengan kesimpulan saya tentang masalah keterbatasan basis data .


8
Saya merasakan untuk Anda, tetapi tampaknya Anda sudah tahu mengapa kendala adalah ide yang baik, jadi tidak banyak yang ditambahkan dalam bentuk jawaban. Saya akan mencatat, bahwa kurangnya kendala bukanlah fenomena baru, saya telah melihatnya selama beberapa dekade dalam database yang dirancang oleh pengembang tanpa pemahaman yang kuat tentang database relasional. Saya pikir itu jarang keputusan desain yang disengaja.
JacquesB

1
@ JacquesB: Anda dapat memposting jawaban, karena "Saya telah melihatnya selama beberapa dekade" memberikan visi yang sangat berbeda bahwa fenomena yang saya miliki tentang fenomena yang muncul tiga-empat tahun yang lalu (mengingat bahwa saya telah bekerja di IT kurang dari satu dekade, pandangan saya tentang fenomena ini mungkin salah). Jadi, kesimpulannya akan sangat berbeda juga.
Arseni Mourzenko

1
Kami bekerja dengan banyak klien. Dan sementara meluncurkan versi baru dari perangkat lunak kami adalah hal yang mudah, memperbarui semua basis data di mana-mana adalah hal yang merepotkan. Itu sebabnya kami memiliki banyak kendala dalam perangkat lunak. Ohh ya, tinyint untuk persentase sering bukan ide yang baik karena persentase bisa menjadi pecahan.
Pieter B

1
Voting untuk membuka kembali pertanyaan ini karena telah salah ditutup sebagai "berdasarkan pendapat" ketika jawaban sejauh ini menunjukkan bahwa tidak demikian halnya.
David Arno

3
Aku bersamamu 110%.
Periata Breatta

Jawaban:


28

Penting untuk membedakan antara berbagai kasus penggunaan untuk basis data.

Basis data bisnis tradisional diakses oleh beberapa aplikasi dan layanan independen dan mungkin langsung oleh pengguna yang berwenang. Sangat penting untuk memiliki skema dan kendala yang dipikirkan dengan matang di tingkat basis data, sehingga bug atau kekeliruan dalam satu aplikasi tidak merusak database. Basis data adalah bisnis-kritis yang berarti data yang tidak konsisten atau korup dapat memberikan hasil yang merusak bagi bisnis. Data akan hidup selamanya saat aplikasi datang dan pergi. Ini adalah tempat-tempat yang mungkin memiliki DBA khusus untuk memastikan konsistensi dan kesehatan database.

Tetapi ada juga sistem di mana basis data terintegrasi dengan satu aplikasi. Aplikasi yang berdiri sendiri atau aplikasi web dengan satu database tertanam. Selama database secara eksklusif diakses oleh satu aplikasi, Anda dapat mempertimbangkan kendala yang berlebihan - selama aplikasi berfungsi dengan benar. Sistem ini sering dikembangkan oleh pemrogram dengan fokus pada kode aplikasi dan mungkin bukan pemahaman yang mendalam tentang model relasional. Jika aplikasi menggunakan ORM, kendala mungkin dideklarasikan pada level ORM dalam bentuk yang lebih akrab bagi pemrogram aplikasi. Pada akhirnya kami memiliki aplikasi PHP menggunakan MySQL, dan untuk waktu yang lama MySQL tidak mendukung kendala dasar sama sekali, jadi Anda harus bergantung pada lapisan aplikasi untuk memastikan konsistensi.

Ketika pengembang dari berbagai latar belakang ini bertemu, Anda mendapatkan bentrokan budaya.

Ke dalam campuran ini kita mendapatkan gelombang baru dari database "penyimpanan cloud" yang didistribusikan. Sangat sulit untuk menjaga database terdistribusi konsisten tanpa kehilangan manfaat kinerja, sehingga database ini sering menghindari pemeriksaan konsistensi di tingkat database dan pada dasarnya memungkinkan para programmer menanganinya di tingkat aplikasi. Aplikasi yang berbeda memiliki persyaratan konsistensi yang berbeda, dan sementara mesin pencari Google memprioritaskan ketersediaan di seluruh server mereka, saya berani bertaruh sistem penggajian mereka berjalan pada basis data relasional dengan banyak kendala.


5
+! 1 untuk menyebutkan gajah di dalam ruangan: asumsi salah bahwa satu aplikasi hanya menggunakan satu DB dan satu DB digunakan hanya oleh satu aplikasi
Tulains Córdova

4
@ TulainsCórdova, saya pikir gajah di ruangan di sini adalah sistem penggajian Google. :)
Machado

5
@Machado Ini jenius: "Saya berani bertaruh sistem penggajian mereka berjalan pada database relasional dengan banyak kendala."
Tulains Córdova

2
Juga berguna untuk memiliki basis data yang dibatasi dengan benar karena kode aplikasi Anda tidak ACID.
Matthew Whited

3
Hanya untuk menekankan komentar yang dibuat oleh @MatthewWhited, tidak mungkin bagi aplikasi untuk menegakkan beberapa jenis kendala antar-baris / antar-tabel tanpa melakukan penguncian dan menjalankan kueri tambahan. RDBMS dapat melakukannya dengan biaya yang jauh lebih rendah.
David Aldridge

15

Semakin banyak sistem saat ini yang berjalan di lingkungan terdistribusi, di cloud dan mengadopsi teknik untuk "meningkatkan", bukannya "meningkatkan". Itu bahkan lebih penting jika Anda berurusan dengan aplikasi online yang menghadap internet, seperti aplikasi e-commerce.

Yang sedang berkata, semua aplikasi yang seharusnya skala dibatasi oleh Teorema CAP , di mana Anda harus memilih 2 dari 3: Konsistensi, Ketersediaan dan Toleransi Partisi (toleransi kesalahan jaringan).

Dengan mempelajari Teorema CAP Anda akan melihat bahwa tidak ada banyak pilihan, tetapi memilih untuk kehilangan Ketersediaan atau Konsistensi, karena Anda TIDAK PERNAH benar-benar percaya pada Jaringan 100% dari waktu.

Secara umum, beberapa aplikasi mungkin tidak konsisten untuk beberapa waktu yang wajar, tetapi tidak mampu tidak tersedia bagi pengguna. Misalnya, garis waktu yang sedikit tidak berurutan di Facebook atau Twitter lebih baik daripada tidak memiliki akses ke garis waktu sama sekali.

Dengan demikian, beberapa aplikasi memilih untuk melepaskan kendala basis data relasional, karena basis data relasional benar-benar bagus di Konsistensi, tetapi dengan biaya ketersediaan.

Catatan pribadi: Saya sudah kuno juga, dan saya telah bekerja dengan beberapa sistem keuangan yang sangat tua di mana konsistensi data merupakan persyaratan kelas paling sering, dan saya penggemar berat kendala database. Kendala basis data adalah garis pertahanan terakhir terhadap tahun-tahun perkembangan buruk dan tim pengembang yang datang dan pergi.

"Est modus dalam rebus". Mari kita terus menggunakan konsistensi DB "tingkat rendah" di mana konsistensi adalah persyaratan kelas satu. Namun terkadang, melepaskannya bukanlah dosa besar.

-- SUNTING: --

Karena ada suntingan kecil dalam pertanyaan, ada alasan lain yang sah untuk menghilangkan batasan dalam database, IMO. Jika Anda mendesain produk dari awal, di mana Anda mendesain sistem Anda untuk mendukung teknologi multi-database, Anda dapat menerima denominator yang paling tidak umum di antara database yang didukung, dan pada akhirnya tidak menggunakan semua kendala sama sekali, meninggalkan semua logika kontrol untuk aplikasi Anda.

Meskipun itu sah, ini juga merupakan area abu-abu bagi saya, karena saya tidak dapat menemukan mesin database hari ini yang tidak mendukung kendala sederhana seperti yang diusulkan dalam pertanyaan awal.


"Saya hanya tidak dapat menemukan mesin basis data apa pun hari ini yang tidak mendukung kendala sederhana seperti yang diusulkan dalam pertanyaan awal." Apakah MySQL mendukung PERIKSA kendala belum?
Vincent Savard

@VincentSavard, mungkin bukan PERIKSA MS SQL yang tepat, tetapi semacam pembatasan yang dilakukannya: dev.mysql.com/doc/refman/5.7/en/constraint-invalid-data.html
Machado

@Machado - ini bukan tentang kendala spesifik, sama seperti mengidentifikasi ketika kueri menyertakan data yang tidak dapat direpresentasikan dalam tipe yang sesuai. Yang merupakan perbaikan berbeda pada situasi bertahun-tahun yang lalu ketika MySQL mengabaikan nilai-nilai tersebut.
Periata Breatta

1
@PeriataBreatta, di samping catatan, saya tidak pernah sepenuhnya mengerti mengapa MySQL adalah database OSS "de facto" yang dipilih oleh pengembang situs web, ketika PostgreSQL sepenuhnya tersedia dan lebih maju. Mungkin lebih mudah untuk menginstal, saya tidak tahu.
Machado

@machado - Saya tidak bisa memastikan , tetapi saya tahu bahwa pada hari-hari awal (kembali pada pertengahan 90-an) saya cenderung lebih suka mysql daripada postgres (yang tidak diubah namanya menjadi postgresql sampai nanti) karena kesalahpahaman bahwa postgres tidak mendukung SQL (versi awalnya tidak - ia memiliki bahasa permintaan sendiri yang disebut "postquel" - dan saya tidak terus mengikuti perkembangannya sehingga tidak menyadari bahwa mereka menambahkan dukungan SQL di sekitar saat yang sama mysql menjadi tersedia). Jika kesalahpahaman ini umum, mungkin mysql maju hanya karena itu. Dan begitu itu di depan, efek jaringan mengambil alih.
Periata Breatta

10

Apa alasan untuk memodelkan basis data relasional tanpa kendala pemeriksaan dan akhirnya bahkan tanpa kunci asing?

Pertama mari kita perjelas bahwa saya berbicara di sini hanya tentang RDBM, bukan tentang database no-SQL.

Saya telah melihat beberapa database tanpa FK atau PK, apalagi memeriksa kendala tetapi jujur ​​mereka adalah minoritas. Mungkin karena saya bekerja di perusahaan besar.

Dalam pengalaman saya selama bertahun-tahun saya dapat mengatakan bahwa beberapa alasan mungkin:

  • Dalam kasus pemula atau programmer hobi , ack keterampilan keterampilan pemodelan
  • Penggunaan ORM yang ekstensif atau hampir eksklusif tanpa kontak nyata dengan dunia basis data
  • Tidak adanya DBA atau ahli pemodelan data lainnya di tim atau proyek kecil
  • Kurangnya keterlibatan DBA atau ahli pemodelan data dalam tahap pertama pengembangan
  • Keputusan disengaja desain oleh bagian dari komunitas pengembang yang menganggap bahwa bahkan kendala pemeriksaan yang memberlakukan bahwa kolom tertentu hanya dapat memiliki 1,2 or 3nilai, atau bahwa kolom "usia" harus >= 0adalah "memiliki logika bisnis dalam database" . Bahkan klausa standar dianggap oleh beberapa orang sebagai logika bisnis yang bukan milik database, seperti yang Anda lihat dalam beberapa pertanyaan dan jawaban terbaru di situs ini. Pengembang ini yang begitu mempertimbangkan, jelas akan menggunakan kendala sesedikit mungkin dan akan melakukan segalanya dalam kode, bahkan integritas referensial dan / atau unicity. Saya pikir ini adalah posisi yang ekstrem.
  • Penggunaan RDBM sebagai penyimpanan nilai-kunci , baik untuk meniru perilaku tidak-SQL karena persyaratan yang cukup sederhana untuk dipenuhi dengan menggunakan tabel RDBMS sebagai mengisolasi repositori nilai-kunci.
  • Dengan asumsi bahwa basis data akan selalu ditulis oleh "aplikasi" dan bahwa tidak ada yang perlu melakukan pemuatan data besar-besaran, atau mengedit atau menyisipkan baris melalui klien SQL (dalam banyak kasus untuk memperbaiki data buruk aplikasi dimasukkan). Dalam skenario kasus terbaik akan selalu ada aplikasi lain (selain "aplikasi") mengeluarkan instruksi DML ke database: klien SQL.
  • Tidak menyadari bahwa data itu milik pemilik bisnis , bukan milik aplikasi.

Yang mengatakan, saya ingin menyatakan bahwa RDBMS adalah perangkat lunak yang sangat canggih yang telah dibangun di atas bahu raksasa dan telah terbukti sangat efisien untuk banyak persyaratan bisnis, membebaskan para programmer dari tugas-tugas duniawi menegakkan integritas referensial pada serangkaian file biner atau file teks. Seperti yang selalu saya katakan, "kita tidak lagi hidup di dunia satu-aplikasi-satu-basis data" . Paling tidak klien SQL akan mengeluarkan DML di samping "aplikasi". Jadi database harus mempertahankan diri dari kesalahan manusia atau pemrograman sampai batas yang wajar

Dalam jenis persyaratan yang terkenal di mana RDBMS tidak akan skala baik, dengan segala cara merangkul teknologi no-SQL . Tetapi mengkhawatirkan proliferasi basis data relasional tanpa kendala di mana ribuan baris kode (dibuat atau diketik) dikhususkan untuk menegakkan apa yang seharusnya ditegakkan oleh RDBMS untuk Anda dengan cara yang lebih efisien.


3

Ada kendala eksternal yang mendorong keputusan teknologi. Hanya ada beberapa situasi di mana Anda memiliki kebutuhan dan atau kemewahan menggunakan kendala bidang basis data secara teratur.

  1. Perusahaan memiliki pengembang untuk aplikasi dan basis data bersama dengan DBA, tetapi sebagian besar pengembang tidak bekerja di lingkungan seperti ini. Mereka melakukan sebanyak yang mereka bisa dalam kode. Juga, beberapa di sisi database tidak terlibat dalam aturan bisnis. Mereka terutama ada di sana untuk menjaga semuanya tetap berjalan. Mereka tidak akan pernah mendorong kendala di db. Harus berurusan dengan aplikasi lama, integrasi, migrasi, merger, akuisisi, kendala db mungkin merupakan solusi terbaik.
  2. Overloading db dapat membuat hambatan yang tidak mudah dipecahkan dengan melemparkan lebih banyak mesin ke masalahnya. Ada beberapa situasi di mana bahasa db tidak menangani beberapa masalah pemrograman tanpa hit kinerja utama, jadi Anda tidak dapat berencana menggunakan kendala untuk semuanya. Stackoverflow memiliki satu server basis data karena melemparkan 2 pada suatu masalah adalah suatu tantangan.
  3. Pengujian Otomatis - mereka ada di sana tetapi banyak pengembang db terlambat ke pesta bersama dengan kerangka kerja IDE / pengujian.
  4. Penempatan - lebih banyak barang db membuatnya lebih rumit. Apa yang terjadi ketika pembaruan ke basis data klien tidak diizinkan karena ada data yang melanggar batasan? Game over kecuali Anda punya cara untuk mengatasi ini. Di aplikasi Anda, Anda dapat memutuskan untuk membiarkan pengguna menangani ini sesuai kebutuhan atau memerintahkan beberapa admin untuk melakukannya dalam satu batch.
  5. Hanya aplikasi / api / layanan yang akan menulis data ke database jadi mengapa repot-repot? Ini memang menahan sebagian besar waktu yang mengapa itu tidak umum.
  6. Menangani kesalahan db cukup sulit tanpa ratusan kendala kendala untuk bersaing jika semuanya menjadi rusak. Sebagian besar senang membuat koneksi dan mendapatkan nama tabel yang benar.

Banyak tim pengembangan tidak ingin memberikan terlalu banyak kendali kepada pengembang db. Anda beruntung jika mendapat lebih dari satu, jadi liburan sangat menyenangkan. Tidak banyak yang memerlukan kontrol mutlak atas domain basis data dan bertanggung jawab atas setiap kueri, aturan bisnis, kinerja, ketersediaan, keamanan, dan data apa yang masuk ke RAID apa. Berikut adalah prosedur tersimpan yang diizinkan untuk Anda lakukan. Selamat bersenang-senang. Jangan pernah berpikir untuk menyentuh meja.


2

Ini adalah masalah yang saya telah berjuang dengan semua karir saya (hampir 40 tahun) dan juga ketika menulis DBMS saya. Penjelasan tentang titik akhir saya ada di sini: http://unibase.zenucom.com . Jadi inilah pemikiran saya.

  1. Secara umum sebagian besar kendala lebih baik ditangani dalam aplikasi sehingga bagian aplikasi yang berbeda dapat menegakkan batasan yang berbeda. misalnya kode negara mungkin tidak berlaku di semua yurisdiksi.
  2. Sebagai tambahan, waspadalah terhadap%. Markup adalah> 100% atau Anda bangkrut :)
  3. Batasan paling baik dijelaskan secara negatif. yaitu apa yang mereka tidak bisa, bukan apa yang seharusnya. Itu selalu daftar yang lebih sederhana.
  4. Kunci asing selalu baik dan harus digunakan. Titik. FK adalah salah satu dari sedikit konstruksi semantik dalam RDBMS dan sangat berguna. Kesulitan terbesar adalah memutuskan apakah akan membiarkan nilai menjuntai jika FK dihapus atau menggunakan baris dependen sebagai alasan untuk tidak menghapus catatan FK.
  5. Batasan di dunia nyata biasanya lebih kompleks daripada batasan nilai bidang tunggal.
  6. Beberapa kendala, bahkan pada level aplikasi, bekerja melawan operasi yang baik. mis. tanggal yang agresif memeriksa menyembunyikan kesalahan dalam tanggal yang tampaknya baik. Anda perlu kesalahan operator untuk mendapatkan ukuran kesalahan pada tanggal yang terlihat masuk akal.

1

Kendala basis data mungkin merupakan ide yang cerdas, tetapi bagaimana dengan penggunaan praktis untuknya? Ambil batasan persentase Anda. Jika Anda menerapkannya, DB Anda akan dengan senang hati menolak persentase yang tidak valid. Lalu? Anda akan memerlukan logika bisnis untuk menangani pengecualian. Yang sebenarnya berarti logika bisnis yang menulis persentase yang salah sudah gagal di tempat lain. Jadi singkatnya: satu-satunya kendala praktis yang tersisa adalah yang Anda lihat (seperti PK / FK).


15
Saya dengan sopan tidak setuju dengan ini. Jika Anda benar-benar membutuhkan konsistensi data, kendala DB adalah suatu keharusan, khususnya jika logika bisnis Anda gagal. Mereka menggambarkan Anda skenario yang gagal diam-diam akan terjadi, di mana kerusakan yang dilakukan oleh persentase kesalahan yang salah akan diperbanyak lebih lanjut dalam sistem. Jika Anda memiliki batasan DB tentang hal itu, Anda akan gagal dengan cepat, dan dengan demikian memberikan pengembang logika bisnis kesempatan untuk melihat kesalahan lebih awal dan menambal sistem logika bisnis, alih-alih membiarkan data korup ke dalamnya.
Machado

5
Pemahaman saya adalah bahwa jika batasan persentase dilanggar, Anda tidak harus menangani pengecualian ini, karena pelanggaran tersebut menunjukkan bahwa ada bug dalam kode Anda di tempat pertama (baik seseorang menggunakan integer sederhana alih-alih instance Percentagekelas, atau ada kesalahan dalam validasi itu sendiri), yang bertentangan dengan kasus luar biasa (seperti koneksi jaringan turun). Bagi saya, pelanggaran harus mengarah ke HTTP 500 untuk aplikasi web atau crash untuk aplikasi desktop, dan kemudian harus dicatat dan diperbaiki.
Arseni Mourzenko

7
@ThomasKilian: nggak; justru sebaliknya. Data yang salah tidak akan masuk, khususnya karena kendala basis data. Jika logika bisnis Anda benar dalam kode, Anda tidak akan pernah melanggar kendala itu sejak awal. Jika ada bug dalam kode, kendala-kendala itu akan memberi tahu Anda tentang bug ini, sambil menjaga database tetap aman dari memo.
Arseni Mourzenko

9
@ ThomasKilian: Saya tidak berpikir bahwa ada yang berdebat melawan "membuatnya benar di tempat pertama" - mungkin lebih bahwa siapa pun dengan sedikit pengalaman tahu itu adalah ide yang buruk untuk merancang sistem dengan asumsi bahwa Anda akan mendapatkan semuanya benar pada kali pertama dan tidak ada bug atau kesalahan akan pernah terjadi selama masa sistem. Kendala DB memastikan bahwa bug atau kesalahan tidak merusak database.
JacquesB

3
@ JacquesB Saya berperang melawan pabrik angin. Jika Anda menempatkan logika bisnis dalam DB, itu juga bisa gagal seperti di tempat pertama dan tidak menyelamatkan Anda dengan cara yang sama. Tetapi (!) Anda sekarang memiliki logika bisnis yang bukan tempatnya. Percaya bahwa DB dapat menyelamatkan logika bisnis busuk Anda benar-benar salah. Logika dalam DB harus mengikuti aturan yang sama dengan logika bisnis secara keseluruhan.
qwerty_so

1

Lebih sering hari-hari ini, orang menggunakan perangkat lunak (misalnya Entity Framework) untuk menghasilkan tabel dan kolom secara otomatis. Idenya adalah bahwa mereka tidak memerlukan keterampilan SQL, membebaskan kapasitas otak.

Harapan bahwa perangkat lunak akan "menyelesaikan masalah" seringkali tidak realistis, dan itu tidak menciptakan kendala seperti yang manusia lakukan.

Untuk hasil terbaik, buat tabel menggunakan SQL dan tambahkan batasan secara manual, tetapi terkadang orang tidak bisa melakukan ini.


Beberapa kerangka kerja mendukung penambahan PK dan FK (semi) secara otomatis, tentu saja.
David Aldridge
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.