@xdangminhtruongx Nếu giờ mình điều chỉnh Model giốg bạn ở trên (Chỗ comment lưu ObjectId ) thì 1 query có thể lấy đc hết thông tin ra k bạn nhỉ?
Dạng như này
review :{
content:"...",
star:".."
user :{
username:"..",
email:".."},// Tác giả review
comments :[{
content:"...",
user :{
username:"..",
email:".."},// Tác giả comment{...},}]}
Nếu dùng lookup thì lấy đc 3 cái là review, user( tác giả review), và comment. Tác giả comment mình thấy chưa lấy đc bạn à.
Lý do mình rất cần như này vì chỗ thông tin comment m không chỉ cần username mà còn 1 số trường khác nữa. Nếu set vào hết như này thì thông tin nó k thống nhất. Do mình sử dụng api này cho angular. Còn có router get comments theo ID review nữa. (Cái này thì đơn giản vì từ comment model dùng populate là là đc user info luôn. )
Còn cái review này nếu không có cách khác thì thôi đành set cứng theo kiểu shop của bạn. Cũng giúp truy vấn nhanh hơn.
@vunguyen10111995 Blog gì. chú nghĩ anh rảnh thế à =)) yêu cầu của dự án thôi. mà khách hàng ko muốn show modal như của viblo. chọn phát là phải có ảnh rồi hiện kiểu markdown luôn
Mình phải đăng ký để cám ơn bài viết của bạn, bài viết của bạn đã nói rõ bản chất của abstract và interface. Chúc bạn nhiều sức khỏe và share nhiều điều bổ ích.
@huuhung96 Thường thì họ toàn set quan hệ emmbeded như thế này, tại Mongodb họ khuyến khích làm vậy mà. Mình cũng thường làm như vậy, mình có thiết kế một cái Database cho trang web bán hàng bằng Mongodb này, hy vọng có ích với bạn : https://github.com/dangminhtruong/havana/tree/master/model
@xdangminhtruongx Sau 1 hồi lâu search thì mình cũng thấy 1 số người họ tạo quan hệ kiểu này.
Nhưng mình thấy nó kiểu ngược ngược so với thói quen dùng quan hệ trong rails và laravel trước đây .
Mình cũng biết là mongo lưu được cả colection. Nhưng mình vẫn muốn lưu ở dạng ObjectID của nó chứ không set cứng để khi người dùng thay đổi thông tin thì nó cũng đổi theo.
Đúng như bạn nói có thể nó rất dài, nên phương pháp này không cần phải áp dụng trong những trang web đơn giản, ít thành phần . Còn BEM phục vụ mục đích bảo trì code CSS cho một dự án lớn, với nhiều trang và nhiều thành phần khác nhau, giúp các developer trong dự án có thể theo dõi được những thành phần nào được sử dụng ở đâu, thay vì phải lần mò các file để bảo trì, nên dù hơi xấu và dài một chút nhưng sẽ dễ dàng trong việc code hơn.
Mình có note ở cuối là sẽ compile lại file SCSS thành một file CSS duy nhất với toàn bộ code từ các partial nên lúc browser lấy file CSS này từ trình duyệt về sẽ chỉ lấy đúng file này thay vì import bằng CSS (lấy một file main sau đó lấy những file import). Ngoài ra bạn có thể tiến xa hơn bằng việc minify file css đã compile để giảm dung lượng của file hơn nữa! Giúp tăng tốc độ tải file lên rất nhiều.
Hi vọng bạn cảm thấy hữu ích !
THẢO LUẬN
Cảm ơn bạn :v
@xdangminhtruongx Nếu giờ mình điều chỉnh Model giốg bạn ở trên (Chỗ comment lưu ObjectId ) thì 1 query có thể lấy đc hết thông tin ra k bạn nhỉ? Dạng như này
Nếu dùng lookup thì lấy đc 3 cái là review, user( tác giả review), và comment. Tác giả comment mình thấy chưa lấy đc bạn à.
Lý do mình rất cần như này vì chỗ thông tin comment m không chỉ cần username mà còn 1 số trường khác nữa. Nếu set vào hết như này thì thông tin nó k thống nhất. Do mình sử dụng api này cho angular. Còn có router get comments theo ID review nữa. (Cái này thì đơn giản vì từ comment model dùng populate là là đc user info luôn. )
Còn cái review này nếu không có cách khác thì thôi đành set cứng theo kiểu shop của bạn. Cũng giúp truy vấn nhanh hơn.
em cảm ơn anh (bow) em làm được rồi ạ
@vunguyen10111995 Blog gì. chú nghĩ anh rảnh thế à =)) yêu cầu của dự án thôi. mà khách hàng ko muốn show modal như của viblo. chọn phát là phải có ảnh rồi hiện kiểu markdown luôn
định làm blog cá nhân đúng k =))
python à ? có gì cứ hỏi nha. skype hahungkk@hotmail.com
await không dùng với callback là sao ạ
thanks a , e đang từ frontend chuyển qua học backend trước chỉ làm với firebase quen h phải làm với sql nên cũng hơi căng
OK cảm ơn bạn. Giờ có nhiều kỹ thuật nên có thể cái name css của bạn dài, nhưng khi build prod nó chỉ còn 1 vài ký tự thôi, k còn tên cũ nữa.
Mình phải đăng ký để cám ơn bài viết của bạn, bài viết của bạn đã nói rõ bản chất của abstract và interface. Chúc bạn nhiều sức khỏe và share nhiều điều bổ ích.
@huuhung96 Thường thì họ toàn set quan hệ emmbeded như thế này, tại Mongodb họ khuyến khích làm vậy mà. Mình cũng thường làm như vậy, mình có thiết kế một cái Database cho trang web bán hàng bằng Mongodb này, hy vọng có ích với bạn : https://github.com/dangminhtruong/havana/tree/master/model
@xdangminhtruongx Sau 1 hồi lâu search thì mình cũng thấy 1 số người họ tạo quan hệ kiểu này. Nhưng mình thấy nó kiểu ngược ngược so với thói quen dùng quan hệ trong rails và laravel trước đây . Mình cũng biết là mongo lưu được cả colection. Nhưng mình vẫn muốn lưu ở dạng ObjectID của nó chứ không set cứng để khi người dùng thay đổi thông tin thì nó cũng đổi theo.
Theo ý kiến của mình, thì mình nghĩ bạn nên set quan hệ embedded giữa Comment vào trong Review như thế này sẽ ổn hơn nè...
Cảm ơn bạn đã đọc bài viết và chia sẻ
nút clip là nút hình cái cờ đen đen ở trên á
Hay thì clip thôi bạn =))
hay quá bạn ươi
Anh ơi bài viết hay khủng khiếp. Cảm ơn anh vì bài viết.
giỏi thì phải khen chứ (ahihi)