Thiết kế database hệ thống eCommerce MySQL
Như những bài viết trước chúng ta đã hiểu trái tim của một hệ thống Thương Mại Điện Tử (TMĐT) tập trung ở 4 dữ liệu đó là `users`, `products`, `orders`, `inventories`. Đi sâu vào 4 dữ liệu này, thì có lẽ là `products` là một trong những table xử lý phức tạp nhất. Vì sao lại là `products` mà không phải là những dữ liệu khác trong 4 loại hình mà chúng ta đã đề cập trên? Để trả lời câu hỏi thì chúng ta đi một thống kê thực tế như sau.
Với 1 `store` thì có ít nhất 50 sản phẩm chính trên `shopee` và mỗi sản phẩm chính có ít nhất 5 sản phẩm con. Bạn hãy để ý, mỗi sản phẩm đều có `variants`. Như vậy thì products chính là một trong những dữ liệu tập trung nhiều nhất và nó phải nhất quán.
Video thiết kế model Product cho Mongodb:
🚩 Subscribe ➜
#mysql #mongodb #ecommerce
✅ Follow Me:
Blog:
Facebook:
Youtube:
tks anh, rất thích những video phân thích database như thế này, rất thực tế. Hi vọng a viết thêm blog về phân tích như thế này
video rất hữu ích. em đã xem nhiều lần.
2 tháng trôi qua rồi :< anh ra video tiếp theo cho phần này đi ạ.
em cũng mong anh cân nhắc ra series về design các models important trong ecommerce. phần này là product rồi, phần tới sẽ là order, user, inventory..
looking forward you <3
Anh trai của em mãi đỉnh
– Trong MySQL, Thay vì tạo 1 bằng mới, mình có thể thêm 1 trường atri_list_object lưu kiểu string có dạng ListObject như này:
"{k: 'size,' v: 'XL''}, {k: 'color', v: 'red'}"
– Khi muốn lấy ra atri_object thì mình chỉ cần convert string sang listobject.
Làm như này có tối ưu hơn không ạ? Em cảm ơn
A chia sẻ về cách đánh index tối ưu trong SQL với ạ
Hay quá hiếm khi có kênh như thế 😮
13:55 Tại sao không tạo ràng buộc khóa ngoại nối bảng p_attrs với bảng p thông qua p_id vậy anh?
Anh ơi cho em hỏi một câu với ạ !!
– E dùng rabbitMq thì khi em code có rất nhiều message để bắn lên,khi em làm e đã xảy ra tình huống như sau:
+ Không thể quản lý hết được message,có khi em còn quên e đã đặt tên là gì.
– Cách khắc phục em nghĩ là: Sử lý khi table nào thay đổi,thì bắn message của table đó lên để làm, như v dễ quản lý hơn,
em nghĩ là thế,không biết có đúng không,cũng mong anh giải thích và code thử demo cái này với ạ !!!
– Em cảm ơn anh !
thank you so much dude you're a god
Chỗ quey kia a viết cứng các key là dể demo hả a. chứ mà thêm key khác vào là phải update lại câu query?
tks a đã làm video chia sẻ. Giọng đậm chất nhà giáo :v
anh ơi, video xử lý fail job trong rabbitMQ đi a
Video rất hay. Cám ơn anh rất nhiều ạ. Chúc anh và gia đình thật nhiều sức khoẻ
Kinh nghiệm thực tế không phải trường lớp và giảng viên nào cũng chia s. Cảm ơn anh rất nhiều, luôn ủng hộ những video của anh
Cảm Ơn anh rất nhiều ạ!
em mong anh ra video giải đáp về vấn đề như sau ạ:
1. khi nào nên để MQH 1-n hoặc n-n giữa product và category
2. hướng để thiết kế category lồng nhau (cha – con – con cấp 2…. – con cấp n)
ad cho em hỏi thiết kế mối quan hệ giữa model category và product là 1 nhiều hay nhiều nhiều tối ưu hơn hay phụ thuộc vào nghiệp vụ cụ thế
Nội dung ngày càng nâng cao cho, chia sẻ kiến thức thực tế. Chúc kênh ngày càng phát triển. Nếu đã làm thì anh chia sẻ luôn về phần transaction luôn nha anh. Em mới vào nghề nên cũng tò mò hệ thống lớn họ làm như thế nào.
Kiểu danh mục thì vẫn sử dụng SQL nào cũng đc. Đối với log, hay những trường hợp cần write liên tục, lưu dữ liệu lớn thì nên dùng mongo. Tùy trường hợp nào thì nên dùng giải pháp gì, chứ cứ làm toàn mongo ko thì cũng chưa chắc là ổn, nhanh…(mình chia sẻ)
May quá đúng cái đang cần về Msql, a cho em hỏi khi join như thế thì 2 bảng có cần phải ràng buộc bằng foreign key ko ạ. Hay chỉ cần đúng ID để liên kết các bảng . E cảm ơn!