Lược đồ MySQL thanh lịch nhất cho các sản phẩm, tùy chọn và danh mục là gì?

Question

Tôi đã làm việc với một tá hệ thống mẫu (Zen Cart, Cube Cart, v.v.). Mỗi trong số này có cách riêng kỳ lạ của họ về cấu trúc sản phẩm, tùy chọn và loại. Tất cả các tính năng bổ sung dẫn đến tình trạng thẻ của McGuyver'd khiến cho mã hoạt động với tổng số lần kéo.

Vì vậy, sáu năm trước, tôi đã xây dựng công cụ lưu trữ web của riêng mình, đã phát triển qua nhiều năm và trở thành ngăn xếp thẻ của riêng mình. Bây giờ tôi đang thực hiện tổng đại tu trên động cơ. Trong khi không ai động cơ sẽ phù hợp với mọi nhu cầu webstore, tôi đã tự hỏi nếu mô hình sau đây có bất kỳ hạn chế, hoặc nếu có một cách tốt hơn để tạo ra một, bình thường hóa cơ sở dữ liệu linh hoạt, không đáng ghét cho thương mại:

Ghi chú:
option_types = màu sắc, kích thước, vật liệu
options = đỏ, trắng, xanh dương, S, M, L, bông, vải thun, da

khác với nội dung cơ bản bỏ qua trên mục đích (vị trí, năng động, vv .), bất cứ ai nhìn thấy một cách để cải thiện điều này?

Answer 1

Đây là ghi chú/ý kiến ​​của tôi về vấn đề này. Bạn đang mất tích, nhưng tôi sẽ cố hết sức để đoán chúng.

• Categories là ok.

• Xóa id từ item_categories khi bạn không sử dụng. Tạo khóa chính kết hợp trên category_id và item_id.

cho mỗi bản ghi một id duy nhất là thông minh hơn bằng nhiều cách: nhanh hơn để tra cứu trên một lĩnh vực hơn trên hai, an toàn hơn để xóa, vv

tra cứu Bạn sẽ làm gì trên id đó? Các truy vấn bạn sẽ chạy là: "Lấy tất cả các danh mục cho một mục" và "Lấy tất cả các mục cho một danh mục". Tôi không hiểu tại sao nó sẽ an toàn hơn để xóa. Tuy nhiên, tôi muốn nói thêm một id có thể không an toàn để chèn vì bạn có thể có các id khác nhau nhưng cùng một cặp category_id và item_id. Bạn sẽ phải kiểm tra những hạn chế đó và chắc chắn rằng các cặp là duy nhất (và không phải là những gì PKS được sử dụng để?)

• items là ok ... (xem bình luận dưới đây)
• Remove id từ item_options (giống trường hợp như trên và xem nhận xét dưới đây)
• option_types là ok

Bây giờ, tôi nghĩ rằng các mục cách và tùy chọn có liên quan sẽ đòi hỏi suy nghĩ nhiều hơn nữa. Nó có vẻ là một mối quan hệ nhiều-nhiều. Là một vật phẩm, chẳng hạn như áo phông có thể có nhiều kích cỡ, có nghĩa là mỗi cặp và các tùy chọn phải có kích thước khác nhau. Nhưng những gì xảy ra khi, ngoài kích thước bạn cũng có một vật liệu khác nhau, chẳng hạn như bông và da. Bạn sẽ phải có thông tin về các cặp bông-S, bông-M, bông-L và da-S, da-M và da-L. Điều này có ý nghĩa vì tôi khá chắc chắn tất cả trong số họ sẽ có một mức giá và trọng lượng khác nhau. Nhưng bây giờ hãy thêm 2 màu vào áo phông của chúng tôi. Bạn sẽ phải thêm giá và trọng lượng cho mỗi 12 kết hợp chúng tôi sẽ có ngay bây giờ.

Chưa kể rằng nếu người dùng muốn xem giá của mặt hàng, anh ta sẽ phải chọn tất cả các tùy chọn cho đến khi đạt đến giá. Tôi không chắc làm thế nào điều này nên được thực hiện như tôi không nhận thức được requiremets. Tôi chỉ cần ném một ý tưởng: bạn có thể áp dụng các biến giá và trọng lượng so với giá cơ sở và trọng lượng sẽ là một phần của mặt hàng đó.

Chỉ cần một vài suy nghĩ chưa qua chế biến trước khi đi ngủ:

• option_types có thể là một số loại hệ thống phân cấp
• Cẩn thận suy nghĩ về cách bạn sẽ xử lý stock cho thiết kế đó. Bạn sẽ có 10 món đồ cho một chiếc áo phông màu đen ... nhưng bạn sẽ có bao nhiêu đồ cho một chiếc áo phông da đen? Số đó liên quan đến 10 bản gốc như thế nào?

Answer 2

Bảng tùy chọn Tôi sẽ thêm giá trị dưới tên. ví dụ: Đen L Đen M Đen S Xanh L Xanh M Xanh S , vv như một spin off để ý tưởng Mosty của.