Đừng ngần ngại đặt các ràng buộc trên cơ sở dữ liệu. Bạn chắc chắn sẽ có một cơ sở dữ liệu nhất quán và đó là một trong những lý do tốt để sử dụng cơ sở dữ liệu. Đặc biệt nếu bạn có một số ứng dụng yêu cầu nó (hoặc chỉ một ứng dụng nhưng với chế độ trực tiếp và chế độ hàng loạt sử dụng các nguồn khác nhau).
Với MySQL, bạn không có các ràng buộc nâng cao như bạn sẽ có trong postgreSQL nhưng ít nhất các ràng buộc khóa ngoại khá tiên tiến.
Chúng ta sẽ lấy một ví dụ, một bảng công ty có bảng người dùng chứa những người từ công ty này
CREATE TABLE COMPANY (
company_id INT NOT NULL,
company_name VARCHAR(50),
PRIMARY KEY (company_id)
) ENGINE=INNODB;
CREATE TABLE USER (
user_id INT,
user_name VARCHAR(50),
company_id INT,
INDEX company_id_idx (company_id),
FOREIGN KEY (company_id) REFERENCES COMPANY (company_id) ON...
) ENGINE=INNODB;
Hãy xem mệnh đề ON UPDATE :
- TRÊN CẬP NHẬT GIỚI HẠN : mặc định : nếu bạn cố cập nhật company_id trong bảng CÔNG TY, công cụ sẽ từ chối thao tác nếu ít nhất một NGƯỜI DÙNG liên kết với công ty này.
- CẬP NHẬT KHÔNG CÓ HÀNH ĐỘNG : giống như GIỚI HẠN.
- TRÊN CẬP NHẬT CASCADE : thông thường tốt nhất : nếu bạn cập nhật company_id trong một hàng CÔNG TY, công cụ sẽ cập nhật nó phù hợp trên tất cả các hàng NGƯỜI DÙNG tham khảo CÔNG TY này (nhưng không có kích hoạt nào được kích hoạt trên bảng USER, cảnh báo). Động cơ sẽ theo dõi các thay đổi cho bạn, thật tốt.
- TRÊN CẬP NHẬT NULL : nếu bạn cập nhật company_id trong một hàng bảng CÔNG TY, công cụ sẽ đặt USER_ company_id liên quan thành NULL (nên có sẵn trong trường USER company_id). Tôi không thể thấy bất kỳ điều thú vị nào để làm với điều đó trên một bản cập nhật, nhưng tôi có thể sai.
Và bây giờ về phía BẬT XÓA :
- TRÊN XÓA HẠN CHẾ : mặc định : nếu bạn cố xóa Id công ty_id trong bảng CÔNG TY, công cụ sẽ từ chối thao tác nếu một NGƯỜI DÙNG ít nhất liên kết trên công ty này, có thể cứu mạng bạn.
- TRÊN XÓA KHÔNG CÓ HÀNH ĐỘNG : giống như GIỚI HẠN
- TRÊN XÓA CASCADE : nguy hiểm : nếu bạn xóa một hàng công ty trong bảng CÔNG TY, công cụ cũng sẽ xóa các NGƯỜI DÙNG có liên quan. Điều này nguy hiểm nhưng có thể được sử dụng để thực hiện dọn dẹp tự động trên các bảng thứ cấp (vì vậy nó có thể là thứ bạn muốn, nhưng chắc chắn không phải là ví dụ về CÔNG TY <-> USER)
- TRÊN XÓA THIẾT LẬP NULL : handful : nếu bạn xóa một hàng CÔNG TY, các NGƯỜI DÙNG có liên quan sẽ tự động có mối quan hệ với NULL. Nếu Null là giá trị của bạn đối với người dùng không có công ty thì đây có thể là một hành vi tốt, ví dụ có thể bạn cần giữ người dùng trong ứng dụng của mình, với tư cách là tác giả của một số nội dung, nhưng loại bỏ công ty không phải là vấn đề đối với bạn.
thông thường mặc định của tôi là: TRÊN XÓA HẠN CHẾ TRÊN CẬP NHẬT CASCADE . với một số ON DELETE CASCADEbảng theo dõi (nhật ký - không phải tất cả nhật ký--, những thứ tương tự) và ON DELETE SET NULLkhi bảng chính là 'thuộc tính đơn giản' cho bảng chứa khóa ngoại, như bảng JOB cho bảng USER.
Biên tập
Lâu lắm rồi tôi mới viết như vậy. Bây giờ tôi nghĩ rằng tôi nên thêm một cảnh báo quan trọng. MySQL có một giới hạn tài liệu lớn với các tầng. Cascades không kích hoạt kích hoạt . Vì vậy, nếu bạn quá tự tin vào công cụ đó để sử dụng các kích hoạt, bạn nên tránh các ràng buộc theo tầng.
Các trình kích hoạt MySQL chỉ kích hoạt các thay đổi được thực hiện đối với các bảng bằng các câu lệnh SQL. Chúng không kích hoạt các thay đổi về chế độ xem cũng như các thay đổi đối với các bảng được tạo bởi các API không truyền các câu lệnh SQL đến Máy chủ MySQL
==> Xem bên dưới chỉnh sửa cuối cùng, mọi thứ đang di chuyển trên miền này
Kích hoạt không được kích hoạt bởi các hành động quan trọng nước ngoài.
Và tôi không nghĩ rằng điều này sẽ được sửa chữa một ngày. Các ràng buộc khóa ngoài được quản lý bởi bộ lưu trữ InnoDb và Triggers được quản lý bởi công cụ SQL SQL. Cả hai đều tách ra. Innodb là bộ lưu trữ duy nhất có quản lý ràng buộc, có thể họ sẽ thêm các kích hoạt trực tiếp vào công cụ lưu trữ một ngày nào đó, có thể không.
Nhưng tôi có ý kiến của riêng tôi về yếu tố nào bạn nên chọn giữa việc triển khai trình kích hoạt kém và hỗ trợ ràng buộc khóa ngoại rất hữu ích. Và một khi bạn sẽ quen với tính nhất quán của cơ sở dữ liệu, bạn sẽ thích PostgreSQL.
12/2017-Cập nhật Chỉnh sửa này về MySQL:
như tuyên bố của @IstiaqueAhmed trong các bình luận, tình hình đã thay đổi về chủ đề này. Vì vậy, hãy theo liên kết và kiểm tra tình hình cập nhật thực sự (có thể thay đổi một lần nữa trong tương lai).
ON DELETE CASCADE : dangerous- uống với một nhúm muối.