Kapan menggunakan "ON UPDATE CASCADE"

Saya menggunakan "ON DELETE CASCADE" secara teratur tetapi saya tidak pernah menggunakan "ON UPDATE CASCADE" karena saya tidak begitu yakin dalam situasi apa ini akan berguna.

Demi diskusi, mari kita lihat beberapa kode.

CREATE TABLE parent (
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (id)
);

CREATE TABLE child (
    id INT NOT NULL AUTO_INCREMENT, parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);

Untuk "ON DELETE CASCADE", jika orang tua dengan yang iddihapus, catatan pada anak dengan parent_id = parent.idakan dihapus secara otomatis. Ini seharusnya tidak menjadi masalah.

1. Ini berarti "ON UPDATE CASCADE" akan melakukan hal yang sama ketika idinduknya diperbarui?

2. Jika (1) benar, itu berarti bahwa tidak perlu menggunakan "ON UPDATE CASCADE" jika parent.idtidak dapat diupdate (atau tidak akan pernah diperbarui) seperti ketika itu AUTO_INCREMENTatau selalu diatur untuk menjadi TIMESTAMP. Apakah itu benar?

3. Jika (2) tidak benar, dalam situasi apa kita harus menggunakan "ON UPDATE CASCADE"?

4. Bagaimana jika saya (karena alasan tertentu) memperbarui child.parent_idmenjadi sesuatu yang tidak ada, kemudian akan dihapus secara otomatis?

Yah, saya tahu, beberapa pertanyaan di atas dapat diuji secara terprogram untuk dipahami tetapi saya ingin juga tahu apakah semua ini tergantung pada vendor database atau tidak.

Tolong beri sedikit cahaya.

Memang benar bahwa jika kunci utama Anda hanya nilai identitas yang ditambahkan secara otomatis, Anda tidak akan memiliki kegunaan nyata untuk ON UPDATE CASCADE.

Namun, katakanlah kunci utama Anda adalah kode batang UPC 10 digit dan karena ekspansi, Anda perlu mengubahnya menjadi kode batang UPC 13 digit. Dalam hal ini, ON UPDATE CASCADE akan memungkinkan Anda untuk mengubah nilai kunci utama dan tabel apa pun yang memiliki referensi kunci asing untuk nilai akan diubah sesuai.

Mengacu pada # 4, jika Anda mengubah ID anak ke sesuatu yang tidak ada di tabel induk (dan Anda memiliki integritas referensial), Anda harus mendapatkan kesalahan kunci asing.

1. Ya, itu berarti bahwa misalnya jika Anda melakukan UPDATE parent SET id = 20 WHERE id = 10semua anak, parent_id dari 10 juga akan diperbarui menjadi 20

2. Jika Anda tidak memperbarui bidang yang dimaksud dengan kunci asing, pengaturan ini tidak diperlukan

3. Tidak dapat memikirkan penggunaan lainnya.

4. Anda tidak dapat melakukan itu karena batasan kunci asing akan gagal.

Saya pikir Anda sudah cukup memaku poin!

Jika Anda mengikuti praktik terbaik desain basis data dan kunci utama Anda tidak pernah dapat diperbarui (yang menurut saya harus selalu menjadi alasannya), maka Anda tidak pernah benar-benar membutuhkan ON UPDATE CASCADEklausa.

Zed membuat poin yang baik, bahwa jika Anda menggunakan kunci alami (misalnya bidang reguler dari tabel database Anda) sebagai kunci utama Anda, maka mungkin ada situasi tertentu di mana Anda perlu memperbarui kunci utama Anda. Contoh terbaru lainnya adalah ISBN (Nomor Buku Standar Internasional) yang berubah dari 10 menjadi 13 digit + karakter beberapa waktu yang lalu.

Ini tidak terjadi jika Anda memilih untuk menggunakan kunci pengganti (misalnya yang dibuat secara sistem) sebagai kunci utama Anda (yang akan menjadi pilihan pilihan saya dalam semua kecuali kesempatan yang paling jarang terjadi).

Jadi pada akhirnya: jika kunci utama Anda tidak pernah berubah, maka Anda tidak perlu ON UPDATE CASCADEklausa.

Marc

Beberapa hari yang lalu saya punya masalah dengan pemicu, dan saya sudah tahu itu ON UPDATE CASCADEbisa berguna. Lihatlah contoh ini (PostgreSQL):

CREATE TABLE club
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE band
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE concert
(
    key SERIAL PRIMARY KEY,
    club_name TEXT REFERENCES club(name) ON UPDATE CASCADE,
    band_name TEXT REFERENCES band(name) ON UPDATE CASCADE,
    concert_date DATE
);

Dalam masalah saya, saya harus mendefinisikan beberapa operasi tambahan (pemicu) untuk memperbarui tabel konser. Operasi-operasi itu harus memodifikasi club_name dan band_name. Saya tidak dapat melakukannya, karena referensi. Saya tidak bisa memodifikasi konser dan kemudian berurusan dengan tabel klub dan band. Saya juga tidak bisa melakukannya dengan cara lain. ON UPDATE CASCADEadalah kunci untuk menyelesaikan masalah.

Komentar saya terutama mengacu pada poin # 3: dalam keadaan apa ON UPDATE CASCADE berlaku jika kita mengasumsikan bahwa kunci induk tidak dapat diperbarui? Ini ada satu kasus.

Saya berurusan dengan skenario replikasi di mana beberapa database satelit perlu digabungkan dengan master. Setiap satelit menghasilkan data pada tabel yang sama, jadi penggabungan tabel ke master menyebabkan pelanggaran batasan keunikan. Saya mencoba menggunakan ON UPDATE CASCADE sebagai bagian dari solusi di mana saya menambahkan kembali tombol-tombol pada setiap penggabungan. TENTANG PEMBARUAN CASCADE harus menyederhanakan proses ini dengan mengotomatiskan bagian dari proses.

Ini pertanyaan yang sangat bagus, saya punya pertanyaan yang sama kemarin. Saya memikirkan masalah ini, khususnya PENCARIAN jika ada sesuatu seperti "ON UPDATE CASCADE" dan untungnya para desainer SQL juga memikirkan hal itu. Saya setuju dengan Ted.strauss, dan saya juga berkomentar tentang kasus Noran.

Kapan saya menggunakannya? Seperti yang ditunjukkan Ted, ketika Anda menangani beberapa basis data pada satu waktu, dan modifikasi pada salah satu dari mereka, dalam satu tabel, memiliki jenis reproduksi apa pun yang disebut Ted sebagai "basis data satelit", tidak dapat disimpan dengan yang asli ID, dan untuk alasan apa pun Anda harus membuat yang baru, jika Anda tidak dapat memperbarui data yang lama (misalnya karena izin, atau jika Anda mencari tahan luntur dalam kasus yang sangat singkat sehingga tidak layak mendapatkan penghormatan mutlak dan total terhadap aturan normalisasi total, hanya karena akan menjadi utilitas yang sangat singkat)

Jadi, saya setuju dalam dua hal:

(A.) Ya, seringkali desain yang lebih baik dapat menghindarinya; TAPI

(B.) Dalam kasus migrasi, mereplikasi database, atau menyelesaikan keadaan darurat, itu adalah ALAT BESAR yang untungnya ada di sana ketika saya pergi untuk mencari jika ada.