Có hay không tạo các bảng riêng biệt cho các loại sản phẩm khác nhau?

25

Tôi đang trong quá trình thiết kế cơ sở dữ liệu và tôi có suy nghĩ thứ hai về các quyết định thiết kế ban đầu của mình ...

Các loại sản phẩm như sau ... Mô hình, bộ phận, bộ dụng cụ thay thế và các tùy chọn.

Tùy chọn A (thiết kế đầu tiên): Tôi dự định có các bảng riêng biệt cho các loại sản phẩm trên. Tôi muốn nói rằng khoảng 75% các trường sẽ giống nhau trong mỗi bảng.

Tôi đã tạo từng loại sản phẩm dưới dạng các bảng riêng biệt do các liên kết tôi cần tạo giữa chúng. Chẳng hạn, một Model có thể có nhiều tùy chọn và một tùy chọn có thể có nhiều model. Một tùy chọn cũng có thể có nhiều phần và một phần có thể có nhiều tùy chọn ... và cứ thế ...

Tùy chọn B: Thay vì có các bảng riêng biệt, tôi có thể tạo một bảng có tên là Sản phẩm bao gồm mô hình, bộ phận, bộ dụng cụ thay thế và các tùy chọn. Tôi có thể có một trường được gọi là loại để phân biệt giữa mô hình, tùy chọn, v.v. Tôi cho rằng một mặt trái là một số trường sẽ không bao giờ được sử dụng (không có giá trị) cho một số loại sản phẩm nhất định. Tôi đoán đây là nơi "không thực hành tốt nhất" sẽ phát huy tác dụng ..

Tùy chọn B sẽ giảm đáng kể độ phức tạp của thiết kế db. Tôi cũng sẽ không phải lo lắng về việc tham chiếu một loạt các bảng khi rút dữ liệu cho các truy vấn ...

database-design database-recommendation

— thanh toán
nguồn

2

Tại poin này, tôi khuyên bạn nên tạo các bảng tính mô phỏng bố cục bảng của bạn và điền chúng vào dữ liệu. Điều này sẽ phơi bày bất kỳ điểm yếu có thể tồn tại.

— Michael Riley - AKA Gunny

Làm thế nào bạn sẽ trỏ khóa ngoại vào các sản phẩm khác nhau nếu chúng ở trong các bảng khác nhau? Đọc lên bảng kế thừa xin vui lòng.

— Neil McGuigan

8

Nếu đây là quyết định thiết kế của tôi, có lẽ tôi sẽ sử dụng nhiều hơn 'Tùy chọn C' (tùy chọn sửa đổi a).

Đầu tiên, tại sao không 'Tùy chọn B':

Đối với một điều, tôi thích sự rõ ràng rằng mỗi sản phẩm có bảng riêng của nó. Nếu đó là tất cả một bảng lớn với một trường để xác định loại, mối quan hệ sẽ không rõ ràng.

Mặt khác, chiến lược lập chỉ mục sẽ luôn yêu cầu trường loại đó được liệt kê. Vì chỉ có 4 loại, nên chỉ số cardinality cực kỳ thấp ( SELECT * FROM product_table WHERE type='X'về cơ bản là thực hiện quét toàn bộ bảng)

Tùy chọn C

Tạo bảng cha chỉ chứa các cột mà tất cả các loại chia sẻ
Tạo mỗi loại sản phẩm dưới dạng bảng riêng với các cột riêng lẻ, có thêm một liên kết: Liên kết đến bảng cha
Tạo mỗi bảng 'liên kết': Product_Option, Model_option, v.v. bằng các liên kết đến các khóa tương ứng.
Đối với những người có liên kết đối ứng (MODEL_OPTION, OPTION_MODEL), hãy tiếp tục và tạo các bảng đó. Điều này sẽ thêm sự rõ ràng trong tham gia của bạn cho bất cứ ai nhìn vào nó.

Nhược điểm là sự phức tạp của việc đảm bảo tránh trẻ mồ côi khi mọi thứ được cập nhật / xóa và ban đầu thiết kế các truy vấn sử dụng các bảng này.

— Derek Downey
nguồn

5

Hiện tại chỉ có 4 loại, nhưng nếu thêm sau này thì sao? Tôi chắc chắn bảng sản phẩm chính của Amazon ban đầu được gọi là "Sách" nhưng bạn có nghĩ rằng bây giờ họ có một bảng riêng cho từng loại sản phẩm không? Tôi không nghĩ mỗi loại nên có bảng riêng nhưng bạn có thể sử dụng mô hình EAV cho các thuộc tính bổ sung mà mỗi loại có thể có chung.

— Aaron Bertrand

1

@Aaron Điểm công bằng về sự gia tăng của các loại sản phẩm trong tương lai. Nếu kịch bản này có thể hình dung có thể mở rộng tới hơn 10 loại sản phẩm, tôi sẽ xem xét lại. Nhưng, tôi cảm thấy các bảng sản phẩm cụ thể là một lựa chọn thiết kế hợp lý cho một lượng nhỏ các loại sản phẩm.

— Derek Downey

1

Tùy chọn C: Có bảng liên kết cần thiết không? Tôi sẽ tưởng tượng PK Product_Option sẽ khớp với PK của bảng Sản phẩm và điều đó sẽ tạo ra sự liên kết để liên kết cả hai bảng.

— trả tiền vào

Sử dụng Product_option làm ví dụ, lược đồ sẽ là (trong tâm trí của tôi): id, ProductID, tùy chọnID. productIDsẽ là một FK đến product.id, và optionIDlà một FK đến option.id. Đó là những gì tôi có nghĩa là bảng liên kết. Và vâng, cần thiết trong thiết kế này để cho phép một sản phẩm liên kết với nhiều tùy chọn.

— Derek Downey

Vâng tôi hiểu. Tôi đọc sai những gì bạn gõ .. Rất tiếc.

— trả tiền vào

7

Tôi sẽ đề nghị bạn bắt đầu với mô hình quan hệ "chính xác", tùy chọn của bạn A. Nếu cách sử dụng điển hình của mô hình đó dẫn bạn đến việc không chuẩn hóa ở một số khu vực, đừng ngại làm như vậy.

Tôi đã thảo luận với một đồng nghiệp tuần trước về cách các thiết kế lược đồ thường được coi là một thứ gì đó được đặt trong đá và không bao giờ có thể thay đổi. Thật kỳ lạ, xem xét cách tái cấu trúc trong thực tế được chấp nhận trong mọi lớp khác của ứng dụng, việc tái cấu trúc một lược đồ cơ sở dữ liệu vẫn được xem là không thực tế.

Nếu giao diện cho cơ sở dữ liệu được thiết kế tốt, không có gì ngăn bạn điều chỉnh lược đồ khi bạn tìm hiểu thêm về các mẫu sử dụng hệ thống.

— Mark Storey-Smith
nguồn

2

Điều này nghe có vẻ rất giống với Hóa đơn tài liệu / nhiều quyền thừa kế mà Paul Neilsen mô tả trong Chương 17 của Kinh thánh SQL Server 2008 .

Toàn bộ chương này là một bài đọc rất hay và phần cụ thể giải quyết vấn đề nhiều-nhiều của bạn được tìm thấy trên các trang 416-419.

Đây là cuộc thảo luận tốt nhất mà tôi đã thấy liên quan đến kiểu phần bùng nổ của thiết kế dữ liệu.

— Michael Riley - AKA Gunny
nguồn

Giải pháp này trông tương tự như tùy chọn B (nếu tôi hiểu chính xác, điều mà tôi không chắc là mình làm). Tôi có một bảng chính (Sản phẩm) và bảng "liên kết" (còn gọi là bảng liền kề / BillsofM vật liệu) để tạo liên kết giữa các mô hình, tùy chọn, bộ dụng cụ, v.v. Điều đó có đúng không?

— trả tiền vào

Tôi nghĩ rằng vấn đề bị che mờ vì các tùy chọn. Hãy đưa các tùy chọn ra khỏi cuộc thảo luận chỉ một chút. Các bộ phận là đơn vị nhỏ nhất. Một nhóm các bộ phận tạo nên một mô hình. Một nhóm các bộ phận thay thế dưới dạng một bộ sản phẩm tạo thành một tập hợp con của mô hình. Càng xa càng tốt. Bây giờ các bộ phận có các tùy chọn cho phép đơn giản vì điều này bao gồm hai loại màu (đen, đỏ, crôm) và vật liệu (kim loại, gỗ, nhựa). Bạn cũng đề cập rằng các mô hình có tùy chọn. Là các tùy chọn mô hình tách biệt với các tùy chọn bộ phận hoặc các mô hình dường như chỉ có các tùy chọn vì các bộ phận làm cho các mô hình khác nhau?

— Michael Riley - AKA Gunny

Các bộ phận không có "tùy chọn" trong thiết kế của tôi. Tôi định nghĩa tùy chọn là một cái gì đó đi trên một mô hình cung cấp cho nó chức năng mở rộng. Một tùy chọn được tạo thành từ các bộ phận. Một mô hình có thể có nhiều lựa chọn khác nhau. Một tùy chọn có thể phù hợp với nhiều mô hình khác nhau là tốt.

— payling

Đó không phải là cách bạn đặt câu hỏi của bạn. Trích dẫn: "Ví dụ, một Mô hình có thể có nhiều tùy chọn và một tùy chọn có thể có nhiều mô hình. Một tùy chọn cũng có thể có nhiều phần và một phần có thể có nhiều tùy chọn ... và cứ thế ..." tạo các bảng tính mô phỏng bố cục bảng của bạn và điền chúng với dữ liệu. Điều này sẽ phơi bày bất kỳ điểm yếu có thể tồn tại.

— Michael Riley - AKA Gunny

0

Nếu bạn có thể chụp ảnh một kịch bản có khả năng trong đó sẽ có các truy vấn thường xuyên đi qua cả bốn loại sản phẩm (và dường như có khả năng đối với tôi), thì tùy chọn B của bạn là tốt nhất.

Thay vì để lại nhiều trường không thể sử dụng trong bảng Sản phẩm, tại sao bạn không thêm bảng Model sản phẩm, bảng Part sản phẩm, bảng AlternativePartKit sản phẩm và chỉ có các trường riêng biệt cho các loại đó trong các bảng đó? Sử dụng cùng khóa chính trên các bảng đó như bảng Sản phẩm của bạn. Tham gia bảng Sản phẩm và Mô hình Sản phẩm khi bạn muốn làm việc với Mô hình. Cần xác định xem hồ sơ sản phẩm bạn có là một phần không? Chỉ cần thực hiện tham gia bên trái từ Sản phẩm đến Phần sản phẩm và nếu Phần sản phẩm. [Chính khóa] không có giá trị, bạn có Phần. Nếu nó là null, nó không phải là một phần. Thay phiên, bạn có thể thêm trường ProductType vào bảng Sản phẩm.

— Alan McBee
nguồn

Các trường null sẽ là tối thiểu, vì khoảng 75% các trường sẽ được sử dụng trong mỗi bảng. Tôi đoán tôi lo lắng hơn về mối quan hệ giữa các loại sản phẩm. Tôi sẽ có ba hoặc nhiều bảng liên kết trỏ đến cùng một bảng. Model_has_Option hai khóa chính, cả hai id sản phẩm của bảng sản phẩm, nếu tôi chỉ sử dụng một bảng để thể hiện các loại sản phẩm. Tôi quan tâm hơn nếu đó là điều đúng hay không làm.

— trả tiền vào

Mặc dù có nhiều yếu tố ảnh hưởng đến quyết định "đúng", có hai yếu tố cần xem xét. 1: yêu cầu hiệu suất tổng thể; 2: khả năng thích ứng / độ phức tạp / khả năng bảo trì. Một trong hai cái đó có lẽ quan trọng hơn một chút so với cái kia. Nếu bạn cần tốc độ, hãy chuẩn hóa bằng cách chọn Tùy chọn A. Bạn sẽ có bản sao; đó là mong đợi. Nếu bạn cần thường xuyên sử dụng lược đồ và tốc độ không phải là yếu tố quan trọng nhất, thì Lựa chọn B. Bạn hiểu "đúng" bằng cách biết các ưu tiên của mình, không phải bằng cách tuân thủ "các thực tiễn tốt nhất của người khác".

— Alan McBee