About Tips Javascript! Tips Javascript is a community of software developers getting together to help one another out. The software industry relies on collaboration and networked learning. We provide a place for that to happen. Blog: anonystick.com Facebook: facebook.com/TipJS/ RU-vid: ru-vid.com
Em có 1 thắc mắc, là nếu mình đẩy vào quee như vậy nếu 1 step trong order nó failed thì các service trước đó cũng phải update lại phải không anh. Ví dụ một trước lúc "do payment" thì mình có 1 bước là "update inventory" vậy nếu mình bị failed ở "payment service" thì làm sao để back về update lại cái "inventery service" kia v ah, có phải mình sẽ public 1 event từ con "payment server" thanh toán failed thì con "inventory server" lắng nghe event failed của con "payment service" và update lại phải không anh.
MySQL nó sẽ tự động tính toán plan thực thi tốt nhất, nó sẽ tự thay đổi thứ tự join, nên việc sắp xếp thứ tự bảng chả ảnh hưởng nhiều đến hiệu năng đâu
Khi join nhiều table vs nhau, thường e thấy mn sẽ đặt câu lệnh ON chỉ pk = fk r sau tất cả mới where conditions, nhưng theo kinh nghiệm của e, khi join table tại câu lệnh ON ngoài set điều kiện join pk, fk, e thường đẩy điều kiện where lên câu lệnh ON để khi xuông WHERE số records là ít nhất
2 дня назад
Vãi mưa lãn mạn. Anh em đúng đỉnh. Lúc nào nghe giọng anh chai cũng cười khúc khích. Video hay quá anh ạ
Theo em biết thì left join hay right join thì nó chỉ là trên phía người dùng nhìn thôi còn thực chất nó sẽ 3 giải thuật join (Nested Loop,Hash,Merge).Hệ thống nó sẽ tự quyết định được sẽ chọn giải thuật nào phù hợp nhất mình cũng có thể can thiệp bằng cách đổi thứ tự bảng join hoặc tham số cấu hình...vv.Cái này phải xem chiến lược thực thi mới biết được
Nghe thôi đã thấy kinh hãi tột độ rồi chưa nói đến làm :))) join 5 7 bảng là ngồi query toát mồ hôi. Đây 25 bảng mà còn logic bên trong bảng nữa thì thật đáng sợ 😀
Cách này chỉ tốt khi mà lấy phân trang từ tầm 1 triệu bản ghi trở đi thôi phải không ạ vì thời gian join không đáng kể so với thời gian quét tới 1 triệu ghi trở đi, mà lại sử dụng được cái unique key sẽ nhanh hơn là dùng index, nếu như bản ghi của em chỉ tầm 10k bản ghi thì đánh index là hiệu quả rồi phải không chứ join vào khá tốn hiệu năng ạ.
MongDB chỉ là NoSQL phổ biến nhất, chứ không thực sự là King của NoSQL. Đối với khả linh hoạt thì từ khi MySQL và PostgreSQL hỗ trợ JSON columns thì cũng đã phần nào tăng sự linh hoạt đáng kể cho schema. --- Về tốc độ ghi MongDB vượt trội hơn so với MySQL và PostgreSQL nhưng ở mặt ngược lại với khối lượng data lớn thì MySQL và PostgreSQL lại có khả năng truy xuất/đọc data tốt hơn MongoDB. Nếu balance giữa tốc độ đọc và ghi thì MySQL có ưu điểm nhất. PostgreSQL cũng có ưu điểm ở phần đọc và các tác vụ analytics, cập nhật nhiều, nhiều module feature mới hơn. --- Bản thân mình thì đi làm IT hơn chục năm rồi mình chưa bao h dùng MongoDB, nếu cần write với khối lượng lớn thì write trực tiếp trên Memory hoặc dùng service mà Cloud Provider support (ex: DynamoDB), xong rồi các data này đều chuyển về để lưu ở MySQL/PostgreSQL.
Dạ con chào chú ạ, chú cho con hỏi các video ở kênh chú dành cho đối lượng level nào vậy ạ, con mới tìm hiểu về backend có học được không ạ? Con cảm ơn chú ạ
Mới theo dõi kênh của a dc hơn tuần nay, thật sự một kênh lập trình quá hay, quá bổ ích. Xem nội dung của a e như khai phá thêm kiến thức về thế giới lập trình. Cám ơn a nhiều
