Làm sao để lưu trữ được một sản phẩm được mua với một sản phẩm khuyến mãi đi kèm

[quynhanhnb]

Mình đang được giao nhiệm vụ thiết kế DB cho Module promotion. Nhóm mình đã thiết kế gần xong chỉ còn một vấn đề chưa giải quyết được đó là một sản phẩm được mua mà đi kèm với một sản phẩm khuyến mãi thì làm cách nào lưu trữ và nhận biết được sản phẩm khuyến mãi đó. Mong bà con giúp mình với

[anhtrangram]

Thêm một table nữa bạn ơi, quan hệ nhiều nhiều đó.

[quynhanhnb]

mình đã thêm rồi bạn, nhưng có vẻ không được hợp lí cho lắm. Vì như vậy sẽ làm rối thêm cho các bảng khác liên quan.hic

[Babywolf]

Vấn đề rối thêm ở các bảng khác bạn có thể cho một ví dụ cụ thể hơn không?

[The Old Man]

Mổi một item bán có một sale-code (mã bán) Mã bán chỉ vỏn vẹn 1 hay 2 chr là đủ.
Trong mã bán đó ta chỉ cho trị giá ví dụ như R (regular sale) cho món bán bình thường, S (on sale) cho món khuyến mải, với mã bán này ta có thể gán R (returned) cho món hàng bị trả lại, D (demo) cho món demo, G (gift) cho món quà tặng v.v

Cuối ngày, cuối tuần kéo báo cáo trên Sale-code "R" hay "S" hay "G" là ta có bản báo cáo đầy đủ về loại hàng đã bán ra

[vnntech.com]

chỉ có cách là thêm một bảng hoặc là thêm một field sản phẩm khuyến mãi id, không muốn thêm bảng thì thêm field sản phẩn id khuyến mãi vào bàng sản phẩm luôn.

[megaownage]

Tôi không hiểu bạn muốn nói SP khuyến mãi đi kèm có nghĩa là gì. Tạm đoán là nếu khách hàng mua sản phẩm X sẽ được tặng thêm sp Y.

Nguyên tắc CSDL Liên Kết:

Liên hệ không đồng bộ --->> bảng phụ/bảng nối (intermediate table)

Giải pháp thêm trường SP Khuyến Mãi vào record của SP chính không thể thực hiện được vì khuyến mãi không phải là một việc đồng bộ (uniform) và vĩnh cữu (permanent). Nó chỉ xảy ra trong một thời gian nhất định và mỗi lần xảy ra lại được áp dụng với hình thức khác.

Mô hình căn bản:

SPDangBan <-> BangNoi <-> SPKhuyenMai
(SPKhuyenMai có thể chính là SPDangBan, tùy theo điều kiện thương mại)

VD:

SanPham (MaSP, Các chi tiết khác,....) : MaSSP là khóa chính
KhuyenMai (MaSP, MaSPKM, NgayBatDau, NgayKetThuc, các ct khác,vv...) : MaSP+NgayBatDau+NgayKetThuc là khóa chính

Với VD trên, một truy vấn qua mã sp, trong một thời hạn ngày, sẽ tìm được mã của sản phẩm được kèm theo khuyến mãi (nếu không tìm được, thì có thể kết luận rằng trong thời hạn trên SP này không có khuyến mãi)

Chú thích:
1. Nếu một SP có thể có nhiều SP khuyến mãi thì MaSP+NgayBatDau+NgayKetThuc+MaSPKM là khóa chính
2. Ngày Bắt Đầu và Ngày Kết Thúc là căn bản của thương mãi. Bất cứ một sự kiện/sự việc gì cũng phải có phương pháp để xác định ngày
3. Nếu khuyến mãi có nhiều hình thức (tặng tiền, tặng quà, tặng sp, vv...) thì bạn phải lập bảng khuyến mãi riêng, có một trường cho biết loại KM và các bảng khác)

[suutamcongnghe]

Giải pháp thêm 1 bảng nữa là không ổn, vì rằng: sản phẩm khuyến mãi kèm theo cũng là 1 sản phẩm như những sản phẩm khác. Ở thời điểm X, có thể mua sản phẩm A được tặng kèm sản phẩm B và thời điểm này, sản phẩm B không bán. Nhưng qua thời điểm Y, hết chương trình khuyến mãi thì sản phẩm B vẫn được bán thông thường.

Giải pháp của mình là bổ sung 1 field, field này sẽ chứa mã các sản phẩm khuyến mãi đi kèm, có kiểu char/varchar (thực ra đây là 1 kiểu quan hệ vòng nhiều - nhiều)

Ví dụ: (ở đây mình chỉ demo thông tin chính thôi nha)
- Sanpham(MaSP, TenSP, SanphamKhuyenmai)
Data:
MaSP | TenSP | SanphamKhuyenmai
1 | Compaq CQ62 | 3,4,5
2 | Dell D620 | 3,4
3 | KAS 2011 |
4 | MousePad |
5 | Balo MrVui |

Cách lấy dữ liệu ở cột SanphamKhuyenmai khi mua sản phẩm 1, 2 mình nghĩ chắc đơn giản với các bạn rồi nhỉ?!

[megaownage]

Trích lại lời đã nói trước:


Tôi không hiểu bạn muốn nói SP khuyến mãi đi kèm có nghĩa là gì. Tạm đoán là nếu khách hàng mua sản phẩm X sẽ được tặng thêm sp Y.


Trích lời suutamcongnghe:


sản phẩm khuyến mãi kèm theo cũng là 1 sản phẩm như những sản phẩm khác. Ở thời điểm X, có thể mua sản phẩm A được tặng kèm sản phẩm B và thời điểm này, sản phẩm B không bán. Nhưng qua thời điểm Y, hết chương trình khuyến mãi thì sản phẩm B vẫn được bán thông thường.

Những điều kiện trên định nghĩa một sản phẩm khuyến mãi? Và giả dụ đúng như vậy thì giải pháp bảng phụ tại sao không áp dụng được?

Chính thực ra, tôi không thấy khác bao nhiêu với giải pháp

bổ sung 1 field, field này sẽ chứa mã các sản phẩm khuyến mãi đi kèm, có kiểu char/varchar (thực ra đây là 1 kiểu quan hệ vòng nhiều - nhiều)

Điểm khác uqan trọng nhất là giải pháp bổ sung trường này vướng lỗi chuẩn hóa bậc 1 (1st degree normalisation)

[suutamcongnghe]

sản phẩm khuyến mãi kèm theo cũng là 1 sản phẩm như những sản phẩm khác. Ở thời điểm X, có thể mua sản phẩm A được tặng kèm sản phẩm B và thời điểm này, sản phẩm B không bán. Nhưng qua thời điểm Y, hết chương trình khuyến mãi thì sản phẩm B vẫn được bán thông thường.
viết dài dòng thì nó như sau


sản phẩm khuyến mãi kèm theo cũng là 1 sản phẩm như những sản phẩm khác. Ở thời điểm X, có thể mua sản phẩm A được tặng kèm sản phẩm B và thời điểm này, sản phẩm B có thể không bán (vd: sản phẩm mới ra, tặng kèm để quảng bá) hoặc đang bán bình thường. Nhưng qua thời điểm Y, hết chương trình khuyến mãi thì sản phẩm B vẫn được bán thông thường (trường hợp không bán lúc khuyến mãi).

Nhìn vào dữ liệu demo, bạn sẽ thấy: mousepad, kas vẫn bán bình thường; nhưng nếu mua 1 bộ pc bạn sẽ được tặng 2 món đó (bán với giá = 0đ - xem ở Phong Vũ)

Mình không nói thêm bảng là sai!

Ở đây mình chỉ đề ra giải pháp để giảm table và dễ cho việc thêm dữ liệu. Vì nếu bạn viết application thì ok, nhưng nếu viết web, bạn sẽ thấy mệt khi đường truyền chậm + nhiều sản phẩm tặng kèm.

Về vấn đề chuẩn hóa dữ liệu theo các dạng chuẩn thì theo mình nhớ không lầm (học lâu quá rồi quên, hi hi) thì ở dạng chuẩn cao nhất là 3NF hay BCNF gì đó, trong trường hợp quan hệ n to n thì ta có thể đem khóa của bảng này qua thành 1 field của bảng kia để đơn giản dữ liệu và dễ quản lý vì nó là siêu khóa.

Mình có 1 câu hỏi bổ sung nè:
Theo các bạn, với cách phân chia ngành nghề như sau thì các bạn sẽ create mấy table?
Khoa học tự nhiên -> {Kinh tế -> {Thương mại, Tiếp thị, ...}, Tin học, Toán, ...}

[vuht2000]

viết dài dòng thì nó như sau

Nhìn vào dữ liệu demo, bạn sẽ thấy: mousepad, kas vẫn bán bình thường; nhưng nếu mua 1 bộ pc bạn sẽ được tặng 2 món đó (bán với giá = 0đ - xem ở Phong Vũ)

Mình không nói thêm bảng là sai!

Ở đây mình chỉ đề ra giải pháp để giảm table và dễ cho việc thêm dữ liệu. Vì nếu bạn viết application thì ok, nhưng nếu viết web, bạn sẽ thấy mệt khi đường truyền chậm + nhiều sản phẩm tặng kèm.
Hoàn toàn ngược lại. Thêm bảng nối chính là để làm đơn giản việc insert và cập nhật dữ liệu. Thử hình dung đã có mouse pad, usb, dây đeo chìa khóa, nay cần thay usb bằng ba lô, bạn sẽ cần sục vào từng bản ghi sửa usb thành ba lô. Trong khi dùng bảng nối thì chỉ cần xóa một bản ghi và thêm một bản ghi mới. Tốc độ truy cập cũng vậy, khi cần lấy tên sản phẩm khuyến mại với cách làm của bạn cần tách chuỗi thành từng ID rồi lookup cho từng ID đó. Với bảng nối chỉ cần 1 query là giải quyết xong. Cách nào nhanh hơn thì khỏi phải bàn cãi.


Về vấn đề chuẩn hóa dữ liệu theo các dạng chuẩn thì theo mình nhớ không lầm (học lâu quá rồi quên, hi hi) thì ở dạng chuẩn cao nhất là 3NF hay BCNF gì đó, trong trường hợp quan hệ n to n thì ta có thể đem khóa của bảng này qua thành 1 field của bảng kia để đơn giản dữ liệu và dễ quản lý vì nó là siêu khóa.

Dạng chuẩn 1 yêu cầu dữ liệu trong mỗi trường phải đơn nhất, việc pack nhiều ID vào một trường đã vi phạm yêu cầu này. Mục đích của nó là để dễ dàng thêm và sửa dữ liệu (như đã nhắc ở đoạn trên) và có thể khai báo ràng buộc toàn vẹn dữ liệu. Khi đưa nhiều ID vào một trường thì có thể thêm một ID không tồn tại vào mà không foreign key nào kiểm tra được.
Khi thiết kế CSDL thì dạng chuẩn 1 là bước đầu tiên cần phải đạt được. Cách làm của bạn vì thế không áp dụng được

[The Old Man]

Coi cái hình chú ý vào cái vòng khoanh đỏ.
SCD lả cái Salecode tôi đã nói ở trên.
Soft POS này đang được xử dụng trong một tiệm bán hàng điện tữ lớn ở Little Saigon với cả chục ngàn món hàng và hàng ngày có khuyến mải, quà tặng.
Các món hàng có thề bán bình thường (REG) hay khuyến mải (SAL) hay làm quà tặng (GIFT) mà không phải thay đổi database (inventory) hàng ngày.

Người biết viết code thì nhìn cái hình thì biết phải làm sao rồi.

http://www.vanviet.com/THOISU/Salecode.jpg

[suutamcongnghe]

Hoàn toàn ngược lại. Thêm bảng nối chính là để làm đơn giản việc insert và cập nhật dữ liệu. Thử hình dung đã có mouse pad, usb, dây đeo chìa khóa, nay cần thay usb bằng ba lô, bạn sẽ cần sục vào từng bản ghi sửa usb thành ba lô. Trong khi dùng bảng nối thì chỉ cần xóa một bản ghi và thêm một bản ghi mới. Tốc độ truy cập cũng vậy, khi cần lấy tên sản phẩm khuyến mại với cách làm của bạn cần tách chuỗi thành từng ID rồi lookup cho từng ID đó. Với bảng nối chỉ cần 1 query là giải quyết xong. Cách nào nhanh hơn thì khỏi phải bàn cãi.

Mình có mô tả data mẫu như sau (không kể yếu tố thời gian):
Mua HTC HD7 tặng bao da trị giá 300.000 đ + thẻ nhớ 8g; HTC HD2 tặng bao da trị giá 200.000 đ + thẻ nhớ 8g; HTC HD Mini tặng bao da 200.000 đ + thẻ nhơ 8g.
Nay vì số lượng thẻ 8g còn ít nên điều chỉnh chính sách lại như sau: Mua HTC HD7 tặng bao da trị giá 300.000 đ + thẻ nhớ 8g; HTC HD2 tặng bao da trị giá 200.000 đ + thẻ nhớ 4g; HTC HD Mini tặng bao da 200.000 đ + thẻ nhơ 4g.

Bạn tách data dùm mình thành các bảng như bạn nói và mô tả cách điều chỉnh thông tin khuyến mãi bằng giao diện màn hình (không điều chỉnh bằng câu lệnh SQL nhé)

Coi cái hình chú ý vào cái vòng khoanh đỏ.
SCD lả cái Salecode tôi đã nói ở trên.
Soft POS này đang được xử dụng trong một tiệm bán hàng điện tữ lớn ở Little Saigon với cả chục ngàn món hàng và hàng ngày có khuyến mải, quà tặng.
Các món hàng có thề bán bình thường (REG) hay khuyến mải (SAL) hay làm quà tặng (GIFT) mà không phải thay đổi database (inventory) hàng ngày.

Người biết viết code thì nhìn cái hình thì biết phải làm sao rồi.

http://www.vanviet.com/THOISU/Salecode.jpg

Cái của bác qua tới invoice rồi. Khi vào invoice thì mọi thứ sẽ phải vào detail order.

[The Old Man]

Tôi chỉ lấy cái invoice đã có để làm ví dụ cho coi, chớ ở new transaction khi khách hàng chưa mua gì hết thì không có gì để dẩn chứng.

[gamenhe]

Còn tùy dự án của bạn phức tạp đến mức độ nào nữa, chứ tớ nghĩ cứ làm đơn giản thôi, nếu khuyến mãi cũng là sản phẩm của cửa hàng có thể bán thì thêm 1 trường chứa id sp khuyến mãi chắc là đc, còn sp khuyến mãi lại bao gồm cả sp đang bán và các thứ phụ đi kèm như tiền mặt, thẻ anh ngữ.v.v thì nên tạo 1 bảng với promotion id riêng cho dễ quản lý. Còn phức tạp hơn nữa thì phải nêu cụ thể bài toán ra mới có hướng giải quyết được.