Nếu sử dụng MySQL thiết kế model Products thì đồng nghiệp tôi đã làm cách này hiệu quả ngang Mongodb

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: • Design 4 models mongod...
🚩 Subscribe ➜ / tipsjavascript
#mysql #mongodb #ecommerce
✅ Follow Me:
Blog: anonystick.com
Facebook: / tipjs
KZbin: / tipsjavascript

[@paralineapp1042]

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

[@anonystick]

cảm ơn bạn. Động lực là đây.

[@quoctrungnguyen4977]

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

[@congnamle3632]

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.

[@anhvuuc8693]

tks a đã làm video chia sẻ. Giọng đậm chất nhà giáo :v

[@chiendd1908]

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ẻ

[@anonystick]

Cảm ơn bạn. Chúc bạn nhanh chóng đạt được ước mơ hén.

[@zeanbae9557]

Cảm Ơn anh rất nhiều ạ!

Anh trai của em mãi đỉnh

[@hieuphamquang135]

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)

[@anonystick]

OK bro. sẽ có nhanh nhất.

[@hieuqp]

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

[@anonystick]

Cảm ơn bạn! Chúc bạn đạt được mục tiêu của mình sớm hén.

[@khaio6635]

thank you so much dude you're a god

[@pinh4133]

Hay quá hiếm khi có kênh như thế 😮

[@anonystick]

Cảm ơn em

[@pinh4133]

@@anonystick anh ơi nào có video tiếp theo ạ?

[@anonystick]

@@pinh4133 Tối nay thì #1 về RabbitMQ, em nhớ ấn chuông mà theo dõi hén. Còn video về eCommerce thì tuần sau đó là thiết kế Categories.

[@trungnamle9884]

A chia sẻ về cách đánh index tối ưu trong SQL với ạ

[@anonystick]

Chắc là có nha em

[@QuyNguyen-eh8bb]

anh ơi, video xử lý fail job trong rabbitMQ đi a

[@phamdoan3570]

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!

[@huongsenongthap478]

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ẻ)

[@hahuuo3]

em bị vướng phần variant của product, em để ý trên các trang shoppe,tiki,.. thì mỗi sản phẩm nó lại có các options khác nhau ví dụ quần áo có size và màu, điện thoại thì màu và bộ nhớ, kiểu nó dynamic em chưa hình dung được db vào thiết kế như nào cho hợp lý ạ

[@phucdatnguyen9861]

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?

[@anonystick]

Đâu, dynamic á.

[@ICOReviewtoken]

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ế

[@hdtphat1730]

tuỳ vào nghiệp vụ mà là 1-n hay n-n nha bạn :D

[@ICOReviewtoken]

@@hdtphat1730 uh mình cũng nghĩ vậy như thằng magento 1 cate có nhiều product, mỗi product lại được gán cho nhiều cate khác nhau

[@hungnguyentrong8969]

- 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

[@anonystick]

Đó cũng là một cách đó em. JSON

[@tientainguyen1041]

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 !

[@anonystick]

Ẹc, đặt tên biến phải khoa học, đặt lộn xộn là sẽ xảy ra như em. Tối mai là video đầu tiên trong Series RabbitMQ

[@xuanmanhdao]

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?

[@anonystick]

Demo á em. Chưa nói đến phần index mừ

[@xuanmanhdao]

@@anonystick Em xem nhiều source code thì thấy rất nhiều trường hợp không nối khoá ngoại để tạo ràng buộc các bảng nên em tưởng anh giống như họ có dụng ý gì đó

[@congnamle3632]

@@xuanmanhdao không tạo khóa ngoại là 1 trường phái. Nếu ko tạo khóa ngoại thì việc xóa rất dễ dàng, insert dễ dàng và sẽ ko xảy ra lỗi khi chưa có thằng FK mà lại insert thằng reference => ít lỗi. Tuy nhiên nó sẽ khiến bạn phải code kĩ nếu không sẽ khiến bạn tạo ra những record dư thừa => tính acid ko có. lúc đó thì chỉ có khóc tiếng mán vì có quá nhiều record ma gây nhiễu thông tin.

[@xuanmanhdao]

@@congnamle3632 theo bạn dự án từ mức trung trở lên có nên tạo ràng buộc khoá ngoại giữa các bảng không?