Mối quan hệ nhiều-nhiều trong SQL giữa nhiều bảng

Vâng, mọi thứ ở đó có vẻ ổn. Nhưng ...

Một số lưu ý:

Chúng tôi sẽ sử dụng loại dữ liệu ngắn hơn cho gender cột; Tôi không thấy rằng chúng ta cần 255 ký tự để thể hiện điều đó. (Có giới hạn về kích thước tối đa của hàng được thực thi.) Nếu chỉ có một vài giá trị cho điều đó, chúng tôi sẽ xem xét ENUM kiểu dữ liệu.

Chúng tôi cũng có thể sẽ thêm NOT NULL các ràng buộc trên một số cột đó, chẳng hạn như tên anh hùng, họ, tên. Chúng tôi cũng có thể sẽ thêm DEFAULT '' . Đôi khi, chúng tôi thực sự cần cho phép các giá trị NULL vì một số lý do, nhưng chúng tôi sử dụng NOT NULL bất cứ nơi nào chúng tôi có thể.

Tôi do dự về TEXT cột. Không có gì sai khi sử dụng TEXT loại dữ liệu, nhưng tôi chỉ nghi ngờ rằng chúng có thể đang "ẩn" một số thông tin có thể được lưu trữ tốt hơn trong các cột bổ sung.

Đối với các khóa ngoại, chúng tôi sẽ chỉ định tên cho các ràng buộc, theo mẫu chúng tôi sử dụng và cũng có thể thêm ON UPDATE CASCADE ON DELETE CASCADE

CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID) 
  REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE

Lưu ý về số nhận dạng (tên bảng và tên cột)

Theo cách chúng tôi thực hiện, tất cả tên bảng đều là chữ thường . (Chúng tôi có bộ tùy chọn MySQL buộc tất cả các tên bảng thành chữ thường.) Chúng tôi làm điều này để tránh các vấn đề không tương thích đối với các hệ điều hành / hệ thống tệp khác nhau (một số phân biệt chữ hoa chữ thường và một số thì không).

Ngoài ra, tên bảng là số ít . Tên của bảng đặt tên cho những gì một hàng của bảng đại diện. Chúng tôi cũng không bao gồm _table như một phần của tên.

Tên cột trong MySQL không bao giờ phân biệt chữ hoa chữ thường, nhưng chúng tôi cũng luôn sử dụng chữ thường cho tên cột. Chúng tôi không "camelCase" tên cột của mình, chúng tôi sử dụng ký tự gạch dưới làm dấu phân cách, ví dụ:power_id so với powerID , hero_name so với heroName .

THEO DÕI

"Ghi chú" của tôi ở trên không phải là các quy tắc cụ thể phải tuân theo; đó chỉ là những mẫu chúng tôi sử dụng.

Làm theo các mẫu này không đảm bảo rằng chúng ta sẽ có một phần mềm thành công, nhưng nó giúp ích cho chúng ta.

Để bạn tham khảo, tôi sẽ chỉ cho bạn thấy những chiếc bàn này trông như thế nào khi được xem như "bức ảnh đầu tiên" từ cửa hàng của chúng tôi, như một hình ảnh minh họa của một mẫu khác; đây không phải là không "đúng cách", đó chỉ là "một cách" mà chúng tôi đã ổn định với tư cách là một đội.

CREATE TABLE superhero
( id               INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, hero_name        VARCHAR(255) NOT NULL                COMMENT ''
, first_name       VARCHAR(255) NOT NULL DEFAULT ''     COMMENT ''
, last_name        VARCHAR(255) NOT NULL DEFAULT ''     COMMENT ''
, first_appearance DATE                                 COMMENT 'date superhero first appeared'
, gender           ENUM('female','male','other')        COMMENT 'female,male or other'
, biography_text   TEXT                                 COMMENT ''
, universe         VARCHAR(255)                         COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY superhero_UX1 (hero_name) 
) ENGINE=InnoDB;

CREATE TABLE power
( id               INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, name             VARCHAR(255) NOT NULL                COMMENT ''  
, description_text TEXT NOT NULL                        COMMENT '' 
, PRIMARY KEY(id)
, UNIQUE KEY power_UX1 (name)
) ENGINE=InnoDB;

CREATE TABLE superheropower
( superhero_id   INT UNSIGNED NOT NULL         COMMENT 'pk, fk ref superhero'
, power_id       INT UNSIGNED NOT NULL         COMMENT 'pk, fk ref power'
, PRIMARY KEY(superhero_id, power_id)
, CONSTRAINT FK_superheropower_superhero 
     FOREIGN KEY(superhero_id) REFERENCES superhero(id)
     ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT FK_superheropower_power
     FOREIGN KEY (power_id) REFERENCES power(id) 
     ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;