Tư vấn thiết kế cơ sở dữ liệu

Tôi đang thiết kế một cơ sở dữ liệu cho nhóm bán hàng của chúng tôi để sử dụng như một công cụ báo giá công việc nhanh chóng. Tôi muốn một số thông tin phản hồi về một khía cạnh cụ thể của thiết kế.

Một trích dẫn về cơ bản được xây dựng bằng cách chọn một danh sách các 'hội đồng' được xác định trước với mỗi mức giá thỏa thuận. Một cái nhìn đơn giản về hình thức chính trông như thế này:

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £25'500    | 1 | 1 |   |     |  | 
| RDOL2.2    | £2'000     | 1        |  £1'500    |   | 1 |   |     |  | 
| DOL5.0     | £1'000     | 1        |  £1'200    |   |   | 1 |     |  | 
+------------+------------+----------+------------+---+---+---+ --- +--+

Người dùng chọn một cụm được xác định trước, nhập số lượng và chọn bất kỳ 'tùy chọn' bắt buộc. Mỗi lắp ráp có khả năng có tới 50 tùy chọn có sẵn. Một tùy chọn cũng là một hội đồng được xác định trước (lắp ráp phụ) với giá riêng của nó. 'Tổng chi phí' cho mỗi dòng được tính bằng (chi phí lắp ráp chính * số lượng) + chi phí cho bất kỳ tùy chọn nào.

Khi người dùng di chuyển con trỏ của họ vào hộp tùy chọn, tên và giá của tùy chọn đó được biết đến với họ.

Bây giờ đây là nơi nó trở nên phức tạp. Mỗi hội đồng có danh sách tùy chọn có sẵn của riêng mình. tức là tùy chọn 1 cho 'VSD55' đại diện cho một tổ hợp con khác với tùy chọn 1 cho DOL5.0.

Theo như các hội đồng ở đây là các bảng được đơn giản hóa mà tôi đang sử dụng:

+-----------------+    +------------------------+    +-----------------------------+
| assembly        |    | assembly_option        |    | assembly_option_link        |
+-----------------+    +------------------------+    +-----------------------------+
| assembly_id (PK)|    | assembly_option_id (PK)|    | assembly_option_link_id (PK)|
| assembly_name   |    | assembly_option_name   |    | assembly_id (FK)            |
| unit_cost       |    | option_number          |    | assembly_option_id (FK)     |
+-----------------+    | unit_cost              |    +-----------------------------+
                       +------------------------+

Bảng 'assembly_option_link' về cơ bản xác định các tùy chọn có sẵn cho mỗi cụm.

Bây giờ cho các bảng 'trích dẫn':

 +-----------------+    +------------------------+    
 | quote           |    | quote_assembly         |    
 +-----------------+    +------------------------+    
 | quote_id (PK)   |    | quote_assembly_id (PK) |
 | quote_name      |    | assembly_id (FK)       |
 +-----------------+    | quantity               |
                        +------------------------+    

Bây giờ phần khó khăn là làm thế nào để lưu trữ bất kỳ tùy chọn đã chọn. Tôi có nên mở rộng bảng 'quote_assugging' với tất cả 50 trường tùy chọn mặc dù điều này phá vỡ quy tắc chuẩn hóa. Một hội đồng sẽ không bao giờ được chọn với tất cả 50 tùy chọn nên điều này có vẻ rất không hiệu quả. Về mặt tích cực, giải pháp này cho phép biểu mẫu nhập của người dùng ánh xạ trực tiếp vào bảng giúp mã hóa dễ dàng.

Giải pháp 'bình thường hóa' tôi nghĩ sẽ tạo ra một bảng khác như thế này:

+------------------------------+
| quote_assembly_option        |
+------------------------------+
| quote_assembly_option_id (PK)|
| quote_assembly_id (FK)       |
| assembly_option_id (FK)      |
| quantity                     |
+------------------------------+

Giải pháp này có nghĩa là chỉ có các tùy chọn được chọn được lưu trữ. Ngoài ra, thay vì lưu trữ tùy chọn, tôi có thể lưu trữ 'assembly_option_id' thực tế. Điều này sau đó làm cho việc tính toán tổng chi phí báo giá đơn giản hơn vì tôi không cần phải chuyển đổi giữa 'tùy chọn_number' và 'assembly_option_id' để tra cứu chi phí tùy chọn lắp ráp. Tuy nhiên, nhược điểm lớn của giải pháp này là nó không phù hợp với biểu mẫu nhập của người dùng. Tôi nghĩ rằng tôi sẽ cần phải áp dụng một số mã hóa ưa thích để giao diện biểu mẫu với các bảng.

Bất cứ ai có thể cung cấp bất kỳ lời khuyên thiết kế ở đây xin vui lòng? Tôi hy vọng tôi đã giải thích bản thân mình đủ tốt.

THÔNG TIN THÊM
Đây cũng là một báo cáo báo giá chi tiết mở rộng mọi tùy chọn đã chọn dưới dạng các mục hàng riêng biệt trong phần chính. Ví dụ:

+---------------------------------+------------+----------+------------+
| assembly                        | unit cost  | quantity | total cost |
+---------------------------------+------------+----------+------------+
| VSD55                           | £10'000    | 2        |   £20'000  |
|   - Seal leak protection        | £ 5'000    | 1        |   £ 5'000  |   <-option 1
|   - Motor over temp protection  | £   500    | 1        |   £   500  |   <-option 2
+---------------------------------+------------+----------+------------+
|                                 |            |          |   £25'500  |
+---------------------------------+------------+----------+------------+

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £20'000    | 1 | 1 |   |     |  | 

Nếu ai đó đưa câu nói đó cho tôi, câu hỏi đầu tiên của tôi sẽ là "Tùy chọn 1 cho VSD55 là gì?" Câu trả lời sẽ là "Tôi không biết." Thông tin đó không có trong trích dẫn. Trong trường hợp không chắc rằng người nhận được đến trường một câu hỏi thứ hai, mà câu hỏi sẽ là "không chi phí gì?" Một lần nữa, câu trả lời sẽ là "Tôi không biết." Một sự im lặng rất đáng lo ngại sẽ xảy ra ngay lập tức, trong đó người đưa cho tôi đoạn trích dẫn sẽ tưởng tượng cảm giác sẽ tốt hơn thế nào khi được chạy qua một chuyến tàu.

Tùy chọn phải là chi tiết đơn hàng trên báo giá, cùng với đơn giá, số lượng và tổng giá của chúng. Tùy chọn phải được đặt tên, không được đánh số. Chúng cũng nên xuất hiện trực tiếp dưới hội đồng cha mẹ của chúng, chứ không phải rải rác khắp địa ngục và một nửa Georgia.

Nếu bạn muốn bắn vào tiền của tôi, tốt hơn hết bạn nên làm rõ ràng những gì tôi phải nhận được cho tiền của mình.

Không có gì (nhiều) sai với 50 hộp kiểm trên biểu mẫu giao diện người dùng. Điều đó làm cho nó dễ dàng để lựa chọn. Nhưng mã UI nên đọc các hộp kiểm và chèn thông tin đúng vào các bảng được chuẩn hóa.

Lựa chọn cuối cùng bạn đưa ra là cách tôi sẽ đi với nó. Và trả về hai bảng được nhóm, một cho "hàng chính" và một cho hàng "đã tồn tại" được thu thập cho 50 cột. Giả sử bạn có thể ánh xạ tùy chọn tới ID cột thích hợp đủ dễ dàng (có vẻ như bạn có thể làm mà không mất quá nhiều thời gian).

Điều đó đủ dễ để lặp lại, giả sử một ngôn ngữ như C #, nơi bạn có sẵn LINQ, v.v ... Những điều đó đủ dễ thực hiện, ngay cả khi chúng liên quan đến một chút vòng lặp (đó là mã UI, nó phải được thực hiện tại một số điểm ). Hoặc bạn có thể thực hiện một trục trong cơ sở dữ liệu trước khi quay lại ... điều đó sẽ nhanh hơn. Nhưng nó vẫn sẽ duy trì sự phức tạp.

Nhưng thiết kế của bạn có âm thanh với tôi.

Thêm bảng phụ của bạn có vẻ khá âm thanh đối với tôi là tốt.

Khi xử lý một vấn đề tương tự ở phần cuối của tôi, tôi đã khám phá việc lưu trữ một cây trong bảng order_lines. Trong trường hợp bạn xem xét bất cứ điều gì tương tự, tôi đã có:

• một parent_idtrường thêm cho order_linesvà một khóa ngoại để (parent_id, product_id)tham chiếu(order_line_id, product_id)

• Một ràng buộc kiểm tra để làm cho có một tùy chọn sẽ ngụ ý cha mẹ (trong trường hợp của tôi check((option_id is not null) = (parent_id is not null))).

Nói cách khác, tôi để UI có một từ về cách lưu trữ mọi thứ:

+---------------------------------+------------+----------+------------+
| assembly                        | unit cost  | quantity | total cost |
+---------------------------------+------------+----------+------------+
| VSD55                           | £10'000    | 2        |   £20'000  |
|   - Seal leak protection        | £ 5'000    | 1        |   £ 5'000  |
|   - Motor over temp protection  | £   500    | 1        |   £   500  |
+---------------------------------+------------+----------+------------+

Từ quan điểm mã hóa UI có vẻ đúng. Nhưng nó nhanh chóng cảm thấy sai từ quan điểm quy tắc kinh doanh, trong đó nó đưa ra một loạt các vấn đề đi xuống. (Tôi đã phải đối phó với tất cả các trường hợp đặc biệt trong trình kích hoạt.)

Vì vậy, không được đề xuất ... Trong chừng mực mà tôi gặp phải trường hợp tương tự, cách tiếp cận hiện tại của bạn sẽ ít gặp vấn đề hơn.