Mengapa pencocokan kunci utama / kunci asing tidak digunakan untuk bergabung?

48

Sejauh yang saya bisa temukan banyak DBMS (misalnya mysql, postgres, mssql) menggunakan kombinasi fk dan pk hanya untuk membatasi perubahan pada data, tetapi jarang digunakan untuk secara otomatis memilih kolom untuk bergabung (seperti natural join dengan nama). Mengapa demikian? Jika Anda sudah mendefinisikan hubungan antara 2 tabel dengan pk / fk, mengapa database tidak dapat mengetahui bahwa jika saya bergabung dengan tabel tersebut, saya ingin bergabung dengan mereka di kolom pk / fk?

EDIT: untuk sedikit memperjelas ini:

misalkan saya punya table1 dan table2. table1 satu memiliki kunci asing pada kolom a, yang merujuk ke kunci utama pada table2, kolom b. Sekarang jika saya bergabung dengan tabel ini, saya harus melakukan sesuatu seperti ini:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

Namun, saya sudah mendefinisikan menggunakan kunci saya bahwa table1.a merujuk ke table2.b, jadi bagi saya sepertinya tidak sulit untuk membuat sistem DBMS secara otomatis menggunakan table1.a dan table2.b sebagai kolom gabungan, sehingga orang hanya dapat menggunakan:

SELECT * FROM table1
AUTO JOIN table2

Namun, banyak DBMS tampaknya tidak mengimplementasikan sesuatu seperti ini.

mysql sql-server

— Tiddo
sumber

32

Dalam banyak kasus, ada lebih dari satu cara untuk bergabung dengan dua tabel; Lihat jawaban lain untuk banyak contoh. Tentu saja, orang bisa mengatakan bahwa itu akan menjadi kesalahan untuk menggunakan 'join otomatis' dalam kasus-kasus itu. Maka hanya segelintir kasus sederhana di mana dapat digunakan akan ditinggalkan.

Namun, ada kekurangan parah! Kueri yang benar hari ini, mungkin menjadi kesalahan besok hanya dengan menambahkan FK kedua ke tabel yang sama!

Izinkan saya mengatakan itu lagi: dengan menambahkan kolom, kueri yang tidak menggunakan kolom tersebut dapat berubah dari 'benar' menjadi 'kesalahan'!

Itu adalah mimpi buruk pemeliharaan, bahwa setiap panduan gaya waras akan melarang untuk menggunakan fitur ini. Sebagian besar sudah melarang select *untuk alasan yang sama!

Semua ini akan dapat diterima, jika kinerja akan ditingkatkan. Namun, bukan itu masalahnya.

Ringkasnya, fitur ini hanya dapat digunakan dalam sejumlah kasus sederhana, tidak meningkatkan kinerja, dan sebagian besar panduan gaya akan melarang penggunaannya.

Oleh karena itu tidak mengejutkan bahwa kebanyakan vendor database memilih untuk menghabiskan waktu mereka pada hal-hal yang lebih penting.

1

Kemungkinan akan ada hit kinerja kecil karena harus mencari tahu kolom bergabung daripada mengelompokkannya.

— HLGEM

1

@ HLGEM, Itu mungkin di-cache, dan juga tidak relevan untuk permintaan yang lebih besar. Keuntungannya adalah kita dapat memastikan kunci tidak terlewatkan karena beberapa kesalahan manusia.

— Pacerier

Menambahkan dan mengubah kolom juga dapat merusak NATURAL JOIN(itulah sebabnya saya biasanya menghindarinya), tetapi saya tidak berpikir bahwa itu sendiri seharusnya berarti bahwa dbms tidak dapat mengimplementasikan cara otomatis untuk bergabung dengan tabel berdasarkan kunci asing.

— Jay K

2

Banyak kasus? Pada seribu tabel DB, saya hanya memiliki beberapa kasus hubungan lebih dari 1 antara dua tabel. Bagaimanapun, itu bukan masalah, itu akan cukup untuk menambahkan nama hubungan seperti AUTO JOIN mytable THROUGH myrelation, itu akan sangat menyenangkan.

— Teejay

Itulah yang kami lakukan di .NET SQL builder kami yang dibuat khusus, dengan intellisense, sepertiInnerJoin(SRC_TABLE.rDEST_TABLE.REL_NAME_F01)

— Teejay

27

Kunci asing dimaksudkan untuk membatasi data. yaitu menegakkan integritas referensial. Itu dia. Tidak ada lagi.

Anda dapat memiliki beberapa kunci asing ke tabel yang sama. Pertimbangkan hal berikut di mana pengiriman memiliki titik awal, dan titik akhir.
```
table: USA_States
StateID
StateName

table: Shipment
ShipmentID
PickupStateID Foreign key
DeliveryStateID Foreign key
```
Anda mungkin ingin bergabung berdasarkan status pengambilan. Mungkin Anda ingin bergabung dengan negara pengiriman. Mungkin Anda ingin melakukan 2 gabung untuk keduanya! Mesin sql tidak memiliki cara untuk mengetahui apa yang Anda inginkan.
Anda akan sering melewati nilai skalar. Meskipun skalar biasanya merupakan hasil perhitungan menengah, kadang-kadang Anda akan memiliki tabel tujuan khusus dengan tepat 1 catatan. Jika mesin mencoba mendeteksi kunci foriegn untuk bergabung .... itu tidak masuk akal karena bergabung silang tidak pernah cocok dengan kolom.
Dalam beberapa kasus khusus, Anda akan bergabung di kolom yang tidak unik. Karenanya kehadiran PK / FK di kolom-kolom itu tidak mungkin.
Anda mungkin berpikir poin 2 dan 3 di atas tidak relevan karena pertanyaan Anda adalah kapan ada IS satu hubungan PK / FK antara tabel. Namun kehadiran PK / FK tunggal di antara tabel tidak berarti Anda tidak dapat memiliki bidang lain untuk bergabung selain PK / FK. Mesin sql tidak akan tahu bidang mana yang ingin Anda ikuti.
Katakanlah Anda memiliki tabel "USA_States", dan 5 tabel lainnya dengan FK ke negara bagian. Tabel "lima" juga memiliki beberapa kunci asing satu sama lain. Haruskah mesin sql secara otomatis bergabung dengan tabel "lima" dengan "USA_States"? Atau haruskah itu menggabungkan "lima" satu sama lain? Kedua? Anda bisa mengatur hubungan sehingga mesin sql memasuki loop tak terbatas mencoba untuk bergabung bersama. Dalam situasi ini tidak mungkin mesin sql untuk menebak apa yang Anda inginkan.

Singkatnya: PK / FK tidak ada hubungannya dengan tabel bergabung. Mereka adalah hal-hal yang tidak berkaitan yang terpisah. Itu hanya kecelakaan alam yang sering Anda bergabung di kolom PK / FK.

Apakah Anda ingin mesin sql menebak apakah itu gabungan penuh, kiri, kanan, atau dalam? Saya kira tidak. Meskipun itu bisa dibilang dosa yang lebih rendah daripada menebak kolom untuk bergabung.

— Tuan Tydus
sumber

7

Saya menganggap kunci asing dan normalisasi sangat relevan dengan gabungan tabel.

3

Argumen Anda berlaku ketika kata kunci JOIN normal selalu mencoba mencocokkannya (karena saya salah dalam contoh saya, saya akan memperbaikinya) Namun, banyak gabungan yang dapat diturunkan langsung dari gabungan tersebut, jadi saya tidak melihat alasan mengapa tidak ada sintaksis eksplisit untuk bergabung dengan mereka. Banyak DBMS memang memiliki gabungan alami, yang pada dasarnya melakukan hal yang sama tetapi dengan nama kolom (= buruk). Hal yang sama dapat dilakukan dengan jenis penggabungan ini, misalnya dengan menetapkan operasi GABUNG OTOMATIS.

5

"Ini hanya kecelakaan alam yang sering kamu bergabung di kolom PK / FK" - Saya tidak yakin!

— onedaywhen

2

"Normalisasi?" Saya pikir pemikiran di sini adalah bahwa jika Anda mulai dengan relvar 1NF kemudian didekomposisi menjadi relawan 6NF maka kemungkinannya adalah a) mereka akan memiliki kunci asing pada implementasi dan b) mereka akan sering bergabung dalam pertanyaan.

— onedaywhen

4

Saya akan memilih jika tidak ada "PK / FK tidak ada hubungannya dengan tabel bergabung."

— ypercubeᵀᴹ

11

konsep "kebersamaan." Hubungan r1dan r2dapat digabungkan jika dan hanya jika atribut dengan nama yang sama memiliki tipe yang sama ... konsep ini berlaku tidak hanya untuk bergabung seperti itu tetapi untuk berbagai operasi lainnya [seperti serikat pekerja] juga.

SQL dan Teori Relasional: Cara Menulis Kode SQL yang Akurat Menurut Tanggal CJ

SQL standar sudah memiliki fitur seperti itu, yang dikenal sebagai NATURAL JOIN, dan telah diimplementasikan di mySQL.

Meskipun saran Anda tidak cukup layak, tampaknya itu masuk akal. Dengan SQL Server (yang tidak memiliki dukungan untukNATURAL JOIN ), saya menggunakan SQL Prompt di Management Studio: ketika menulis INNER JOINInteliSense menyarankan ONklausa berdasarkan nama atribut umum dan kunci asing dan saya merasa sangat berguna. Saya tidak punya keinginan besar untuk melihat tipe join SQL standar (baru) untuk ini.

— suatu hari nanti
sumber

1

Gabung & bergabung secara alami pada kolom umum berbeda dari & ortogonal dengan gagasan bergabung di FK-PK. (Lihat jawaban saya.)

— philipxy

@ philipxy: setuju, saya tidak bermaksud menyiratkan sebaliknya. (Ini Anda adalah jawaban yang sangat baik!)

— onedaywhen

9

SQL yang lebih dulu!

Kunci Asing dan batasan Kunci Asing muncul kemudian dan pada dasarnya adalah optimasi untuk aplikasi gaya "transaksi".

Database relasional pada awalnya dipahami sebagai metode penerapan query kompleks pada set data dengan cara yang secara matematis dapat dibuktikan menggunakan aljabar relasional. IE untuk satu set data dan kueri yang diberikan selalu ada satu jawaban yang benar.

Database relasional telah berkembang sejak saat itu, dan ada penggunaan utama sebagai lapisan persistensi untuk sistem transaksional bukan apa yang CODD et. semua dibayangkan.

Namun badan standar ANSI untuk semua tujuan yang saling bertentangan dan politik vendor selalu berusaha untuk menjaga properti SQL yang "dapat dibuktikan secara matematis".

Jika Anda mengizinkan basis data untuk menyimpulkan properti gabungan dari data kunci asing "tersembunyi", Anda akan kehilangan properti ini (pertimbangkan ambiguitas jika ada lebih dari satu set kunci asing yang ditentukan).

Juga seorang programmer yang membaca SQL tidak perlu tahu kunci asing apa yang saat ini didefinisikan untuk dua tabel, dan, perlu memeriksa skema database untuk mengetahui apa yang sedang dilakukan query.

— James Anderson
sumber

3

Terima kasih, ini masuk akal bagi saya! Namun, bukankah gabungan alami memiliki masalah yang sama? Meskipun bergabung secara alami bahkan memiliki masalah yang lebih besar, banyak DBMS mendukungnya. IMO bergabung berdasarkan pk / fk akan menjadi bergabung alami dilakukan dengan benar.

1

Tidak ada perbedaan sejauh menyangkut kebanyakan mesin basis data antara gabungan alami dan "GABUNG ..." yang eksplisit. Mesin menganalisis kueri dan melakukan penggabungan sebaik mungkin berdasarkan berbagai predikat. Menggunakan gabungan eksplisit tidak memaksa penggunaan indeks atau jalur akses tertentu, sebagian besar ada di sana untuk mendukung sintaks bergabung "LEFT, OUTER, INNER" yang perlu mengetahui predikat join eksplisit untuk mengetahui kapan harus memasukkan baris "hilang" .

6

SQL tidak didahulukan! Model relasional (yang termasuk konsep kunci asing tentu saja) pertama kali digariskan oleh EFCodd pada tahun 1969. SEQUEL, seperti itu, tidak melihat cahaya hari sampai sekitar tahun 1974. Para penemunya menjelaskan sejak awal bahwa SEQUEL / SQL dimaksudkan untuk didasarkan pada model relasional yang sudah ada sebelumnya - meskipun SQL gagal menjadi bahasa yang benar-benar relasional.

— nvogel

@sqlvogel - benar! Seharusnya ungkapan itu "SQL diimplementasikan dulu".

— James Anderson

CJ Date dalam 'An Introduction to Database Systems' (hal 276) mengatakan Codd menemukan konsep kunci asing; tidak mengatakan kapan tetapi saya menganggap itu sebelum implementasi SQL pertama.

— oneday ketika

7

Meskipun Anda telah menetapkan hubungan Foreign Key, itu tidak berarti bahwa Anda ingin bergabung dengan tabel di semua kueri. Ini adalah metode yang paling mungkin untuk bergabung dengan tabel, tetapi ada kasus di mana itu tidak benar.

Anda mungkin ingin menggunakan produk Cartesian dari dua tabel atau bagiannya untuk beberapa tujuan.
Mungkin ada bidang lain tempat Anda dapat bergabung untuk tujuan lain.
Jika Anda bergabung dengan tiga tabel atau lebih, salah satu tabel mungkin terkait dengan dua atau lebih tabel. Dalam hal ini biasanya hanya satu dari hubungan-hubungan FK yang mungkin yang mungkin sesuai dalam permintaan.

— BillThor
sumber

7

Anda mungkin beroperasi dengan asumsi yang salah. Anda mengatakan 'sejauh yang Anda bisa tahu' tetapi tidak memberikan bukti empiris atau bukti. Jika pk atau fk adalah indeks terbaik untuk kueri, itu akan digunakan. Saya tidak tahu mengapa Anda melihat ini, tapi dugaan saya kurang bagus.

Edit sekarang bahwa pertanyaannya telah ditulis ulang sepenuhnya: Kasus yang Anda uraikan hanya akan untuk satu set kueri yang sangat kecil. Bagaimana jika ada 12 tabel yang Bergabung? Bagaimana jika tidak ada FK .... Bahkan jika ada gabung standar pada saya masih akan selalu menentukan gabung hanya untuk keterbacaan. (Saya tidak mau harus melihat data dan kemudian mencoba mencari tahu apa yang sedang bergabung)

Beberapa alat Kueri benar-benar melakukan gabung otomatis untuk Anda kemudian memungkinkan Anda menghapus atau mengedit gabung. Saya pikir Query Builder MS Access melakukan ini.

Terakhir, standar ANSII menyatakan bahwa join harus ditentukan. Itu alasan yang cukup untuk tidak mengizinkannya.

— Orang bodoh
sumber

3

Maaf, mungkin saya tidak cukup jelas. Saya tidak berbicara tentang indeks, saya berbicara tentang bergabung. Misalkan saya memiliki table1 dan table2, dengan fk pada table1.a yang menunjuk ke table2.b. Jika saya bergabung dengan tabel ini saya harus secara eksplisit mengatakan bahwa saya ingin bergabung dengan mereka pada kolom a dan b (misalnya 'SELECT * FROM table1 GABUNG table2 ON table1.a = table2.b '), sementara saya sudah mendefinisikan dalam database saya Skema bahwa keduanya terkait. Pertanyaannya adalah mengapa saya tidak bisa melakukan 'SELECT * FROM table1 JOIN table2' dan biarkan DBMS secara otomatis memilih kolom bergabung berdasarkan fk / pk.

3

Terutama keterbacaan yang masuk akal bagi saya! Namun, standar itu mengatakan itu bukan argumen IMO yang benar-benar bagus. Banyak standar telah membuat pilihan yang salah sebelumnya (HTML misalnya).

3

Ada banyak alasan mengapa database tidak dapat melakukan ini dengan aman, termasuk fakta bahwa menambah / menghapus Kunci Asing akan mengubah arti dari permintaan pra-tertulis termasuk permintaan dalam kode sumber aplikasi. Sebagian besar basis data juga tidak memiliki set Kunci Asing yang baik yang mencakup semua kemungkinan bergabung yang mungkin ingin Anda lakukan. Juga untuk nilai yang lebih baik atau berharga, Kunci Asing sering dihapus untuk mempercepat sistem dan tidak dapat digunakan pada tabel yang dimuat dalam urutan "salah" dari file.

Namun tidak ada alasan mengapa alat desain kueri atau editor teks tidak dapat secara otomatis menyelesaikan bergabung dengan bantuan Foreign Keys dengan cara yang sama seperti mereka memberi Anda intellisense pada nama kolom. Anda dapat mengedit kueri jika alat itu salah dan menyimpan kueri yang sepenuhnya ditentukan. Alat semacam itu juga dapat memanfaatkan konvensi penamaan kolom Kunci Asing oleh nama tabel "induk" dan kolom dengan nama yang sama di tabel induk / anak, dll.

(Istri saya masih tidak dapat memahami perbedaan antara Management Studio dan Sql Server dan berbicara tentang memulai sql server ketika ia memulai studio manajemen!)

— Ian Ringrose
sumber

3

Alami bergabung dengan "secara otomatis" bergabung pada persamaan kolom umum, tetapi Anda hanya boleh menulis bahwa jika itu yang Anda inginkan berdasarkan makna tabel dan hasil yang diinginkan Anda. Tidak ada "secara otomatis" mengetahui bagaimana dua tabel "harus" bergabung atau dengan cara lain apa pun tabel "harus" muncul dalam kueri. Kami tidak perlu tahu kendala untuk kueri. Kehadiran mereka hanya berarti input mungkin terbatas dan, akibatnya, outputnya juga mungkin. Anda dapat mendefinisikan beberapa jenis operator join_on_fk_to_pk yang "secara otomatis" bergabung per batasan yang dinyatakan; tetapi jika Anda ingin makna kueri tetap sama jika hanya kendala yang berubah tetapi bukan makna tabel maka Anda harus mengubah kueri tersebut agar tidak menggunakan batasan yang dinyatakan baru.sudah meninggalkan artinya sama meskipun ada perubahan kendala .

Apa yang menjadi kendala (termasuk PK, FK, UNIK & PERIKSA) tidak memengaruhi arti tabel. Tentu saja, jika makna tabel berubah maka kontraint mungkin berubah. Tetapi jika kendala berubah itu tidak berarti bahwa permintaan harus berubah.

Orang tidak perlu tahu kendala untuk query. Mengetahui tentang kendala berarti kita dapat menggunakan ekspresi lebih lanjut yang tanpa pegangan kendala tidak akan menghasilkan jawaban yang sama. Misalnya mengharapkan melalui UNIQUE bahwa sebuah tabel memiliki satu baris, sehingga kita dapat menggunakannya sebagai skalar. Kueri ini dapat pecah jika kendala diasumsikan tetapi tidak dinyatakan. Tetapi menyatakan batasan yang tidak diasumsikan oleh kueri tidak dapat memecahkannya.

Apakah ada aturan praktis untuk membangun query SQL dari deskripsi yang dapat dibaca manusia?

— philipxy
sumber

2

Alasannya adalah bahwa ada BAHASA, dan kemudian ada kepala sekolah yang mendasarinya. Bahasa ini jarang dan kurang dalam banyak fitur yang Anda harapkan untuk melihat dalam bahasa tujuan umum. Ini kebetulan merupakan fitur bagus yang belum ditambahkan ke bahasa dan mungkin tidak. Itu bukan bahasa mati jadi ada harapan, tapi saya tidak akan optimis.

Seperti yang telah ditunjukkan orang lain, beberapa implementasi menggunakan ekstensi di mana bergabung (kolom) bergabung dengan dua tabel berdasarkan nama kolom umum, yang agak mirip. Tapi itu tidak menyebar luas. Perhatikan bahwa ekstensi ini berbeda dari SELECT * FROM employee NATURAL JOIN department;sintaksis yang tidak menyertakan cara untuk menentukan kolom mana yang akan digunakan. Baik mengandalkan hubungan antara tabel, yang membuat mereka tidak dapat diandalkan (sintaks bergabung alami lebih dari ekstensi).

Tidak ada kendala mendasar untuk "tabel gabung dalam pada PKFK" di mana PKFK adalah kata kunci yang berarti "hubungan kunci asing yang didefinisikan antara dua tabel", mungkin ada masalah dengan beberapa fk ke tabel yang sama, tetapi itu bisa saja menyebabkan kesalahan. Pertanyaannya adalah apakah orang-orang yang merancang bahasa tersebut menganggap bahwa a) ide yang bagus dan b) lebih baik untuk dikerjakan daripada beberapa perubahan bahasa lainnya ...

— jmoreno
sumber

3

Ini menganggap itu adalah ide yang baik bahwa mereka seharusnya sudah melakukannya. Kemungkinan besar mereka telah mempertimbangkan hal ini dan memutuskan untuk tidak melakukannya. Mungkin itu adalah ide yang sangat buruk dalam praktiknya: Sjoerd menyebutkan sebuah contoh, di mana kueri dapat dipecahkan hanya dengan menambahkan kolom baru dan hubungan FK. Lord Tydus juga menjelaskan kunci asing yang memiliki tanggung jawab berbeda dari mendikte cara meja Anda harus digabungkan.

1

@JonathanHobbs: Maksud saya jawaban saya umumnya netral. Tapi meninggalkan netralitas. Logikajoerd cacat. Perubahan pada tabel sudah memecah kueri, menambahkan kolom baru ke tabel, kunci utama akan memecah kueri atau mulai mengembalikan hasil yang salah. Ini sebenarnya akan melindungi Anda dari itu sampai batas tertentu, selama hubungan tabel dipertahankan, perubahan kolom bisa dilakukan dengan aman. Ini mungkin akan meningkatkan penggunaan hubungan FK, karena akan berguna untuk sesuatu selain RI. baik di PK atau menyertakan Pk.Untuk menangani multi fk, gunakan nama kolom.

— jmoreno

1

Jika menghilangkan klausa ON diasumsikan mengikuti bidang berdasarkan integritas referensial, bagaimana Anda akan melakukan produk Cartesian?

Sunting: menggunakan AUTO Kelebihan dari ini adalah sedikit mengetik dan Anda tidak perlu tahu bagaimana mereka bergabung atau ingat bergabung dengan rumit. Jika hubungan berubah, itu ditangani secara otomatis, tetapi itu jarang terjadi kecuali dalam pengembangan awal.

Yang harus Anda lakukan sekarang adalah memutuskan apakah semua AUTO Anda bergabung bertahan selama perubahan relasi untuk mencocokkan maksud pernyataan pilihan Anda.

— JeffO
sumber

@ Jeffoff: keuntungan utama adalah bahwa ia mengekspresikan maksud lebih tepat, dengan cara deklaratif yang sangat jelas. Bergabung dengan nama kolom tidak memberi tahu Anda apa pun, selain fakta bahwa beberapa konten kolom serupa dengan yang ada di kolom lain (tetapi mungkin bukan jenis yang sama). Sebuah bergabung pada ref fk, memberitahu Anda bahwa ada adalah ref fk, tidak ada daftar kolom berarti hanya ada 1 fk antara tabel, atau sebaliknya bahwa ada 1+ (mempertimbangkan kunci multicolumn dengan lebih dari 1 ref apa yang terjadi ketika Anda mencampur kolom c1 = fk1_c1 dan c2 = fk2_c2). Bahkan dengan lebih banyak mengetik rata-rata, ini akan bagus.

— jmoreno

Menggunakan (INNER) GABUNG tanpa HIDUP bukan SQL standar. Koma, LINTAS GABUNG & (INNER atau OUTER apa saja) GABUNG 0 = 0 pengembalian produk Cartesian.

— philipxy

-1

mengapa database tidak dapat mengetahui bahwa jika saya bergabung dengan tabel tersebut saya ingin bergabung dengan mereka di kolom pk / fk?

Sebagian alasannya adalah:

1 - secara teori Anda dapat bergabung dengan tabel pada kolom acak dari dua tabel. Meskipun ini bukan praktik umum, itu valid. Ingat bahwa SQL seperti bahasa pemrograman, ia tidak mengerti informasi apa yang ada di dalam kolom tentu saja dan nama, untuk SQL, tidak banyak berarti dalam hal ini.

2 - Ada berbagai jenis sambungan (kiri, kanan, dalam) - Bergabung dalam hanya 1 dari mereka.

3 - Standar SQL dapat dipandu oleh prinsip menjadi bahasa tingkat rendah yang memungkinkan dialek tingkat tinggi untuk membentuk kecerdasan menggunakannya. Perbandingannya agak lebih jelas jika Anda memikirkan bahasa generasi ke-4 vs bahasa generasi ke-3. Bahkan, satu alat yang saya gunakan, IEF, memungkinkan Anda untuk menulis sesuatu seperti ini:

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

Ringkasnya, saran Anda menarik dan dapat diimplementasikan baik sebagai bagian dari standar atau sebagai prosedur tersimpan (standarnya adalah Inner Join).

— Tidak mungkin
sumber

-10

Tiddo, saya yakin Anda sepenuhnya benar, SQL tentang topik itu cukup bodoh , dan saya ingat pernah memikirkan hal yang sama dengan Anda mengenai kunci asing saat mempelajari SQL sekitar sepuluh tahun yang lalu.

Ok, mengingat itu, saya akhirnya harus lulus ujian itu; dan untuk melewatinya, saya harus melepaskannya . SQL lebih merupakan sebuah trainwreck daripada siapa pun mungkin mengakui, jalur standardisasi adalah bencana yang lengkap, dan beberapa implementasi mengancam untuk menyelesaikan lengkap . Masih cukup berguna, secara umum. (Aku bukan luddite K / V)

Kunci asing, lalu ... tidak berguna sama sekali. Mereka adalah konsep penting dalam model relasional , ok, tetapi fitur SQL dengan nama yang sama tidak dapat dibandingkan dengan baik.

Katakan langsung: jangan gunakan fitur SQL yang disebut Foreign Keysama sekali , sampai Anda menekan beberapa sistem besar dengan masalah kinerja. Eksplisit mengatakan mesin yang bidang adalah kunci asing dan yang tidak adalah hanya digunakan untuk mengindeks, dan itu terlihat oleh pengguna db.

Apakah itu menyesatkan?
Iya.

Apakah mereka akan menjadikannya lebih kuat sekarang, setelah 30 tahun orang menyesatkan?
Tidak mungkin.

Mengabaikan Kunci Asing sepenuhnya sampai diperlukan ... memperbaiki SQL untuk saya?
Iya!

Dan mengapa sih semua ini terjadi?
Nah, fitur yang kita sebut kunci asing ditambahkan kemudian, ke SQL; SQL adalah standar yang berkembang seiring waktu, dari bawah ke atas. Vendor menerapkan fitur menggelikan, sementara badan standar facepalmed.

Kunci asing seperti yang dikatakan, di mana hanya dimaksudkan untuk pengindeksan dan tidak ada konstruk GABUNG yang tersedia. (Bergabung ketika dilakukan dengan SELECTqueries, JOINqueries cukup baru dan hanya dimaksudkan untuk SELECTfungsionalitas) Mereka mungkin berpikir bahwa memanggil bendera pengindeksan FOREIGN KEY, adalah hacking penamaan cerdas atas konsep teori db relasional.

13

Berkenaan dengan kunci asing, saya kira Anda hanya pernah menyentuh mesin MyISAM di MySQL? Karena bahkan mengabaikan kata-kata kasar kecil itu, setiap hal dalam jawaban ini salah.

Fk tidak digunakan untuk pengindeksan, pada kenyataannya masalah umum adalah tidak memiliki indeks pada kolom fk yang dapat memiliki dampak kinerja yang dramatis.

— jmoreno