THẢO LUẬN

Chuẩn bị nghỉ việc à em mà chuẩn bị dump câu hỏi như này 😄 Nếu 1 team docker mà phỏng vấn thì anh nghĩ chỉ cần là nữ là 50% pass rồi =)) Theo anh thì em thiên về troubleshooting và microsevices hơn là những câu hỏi kiểu này!

0
thg 12 25, 2019 1:51 SA

-_-

0

Hay quá điii ❤️ bài viết chất lượng

+1

Phương án 1 thì thay vào việc update tất cả bản ghi thường xuyên, ta có thể chỉ cần update từng bản ghi mỗi khi bài viết tương ứng được vote thôi (nếu theo như cách của Reddit).

Nhưng nếu là mình thì sẽ làm như phương án 2, thực thiện tính trong lúc query để đảm bảo thống nhất và tránh dị thường trong CSDL, và dùng cho đến khi nào hệ thống đủ lớn khiến câu truy vấn chậm đáng kể rồi mới tìm cách khác.

Hy vọng có bác tiền bối nào từng triển khai hệ thống tương tự vào đây tư vấn kỹ hơn về vụ này :v

0
thg 12 24, 2019 12:09 CH

Cám ơn bạn đã comment nhé 😄

+1
thg 12 24, 2019 11:36 SA

Thì mình đọc ở đó mới thấy bạn đang nhầm mà, bạn check lại đi nhé.

+1

Đã có công thức vậy cho mình hỏi thêm biện pháp tối ưu để truy vấn được các bản ghi theo rank như vậy với ạ! *** Mình nghĩ đang nghĩ đến 2 phương án như sau nhưng nghe chừng không được tối ưu:

  1. Chạy 1 cronjob với tần suốt 1 ngày 2 lần để tính rank cho từng bài viết rồi sau đó lưu vào bảng rank (post_id, score). Giả sử database có 1 triệu bài viết, vậy nếu làm theo cách này thì phải update 1 triệu bản ghi trong bảng rank => không tối ưu.
  2. Sẽ tính rank trong khi truy vấn. Cách này cũng không tối ưu vì càng nhiều bản ghi thì tốc độ tính toán càng chậm.

Các bạn ai có giải pháp hay comment cho mình với nhé!

0
thg 12 24, 2019 9:42 SA

vâng chúc bạn sức khỏe, sớm ra phần 2 ạ, mình chờ mỏi mắt 😄

0

Bạn tôi giỏi quá ❤️

+1
thg 12 24, 2019 7:44 SA

đọc lại rồi nên upvote rồi nhá =))

0
thg 12 24, 2019 7:42 SA

hay lắm các tn :v

0
thg 12 24, 2019 7:41 SA

may chưa đọc =))

0
thg 12 24, 2019 7:36 SA

đừng đọc chị ơi =))

0
thg 12 24, 2019 7:35 SA

Có hay thật không để còn đọc

0
thg 12 24, 2019 7:22 SA

public function test_product_be_longs_to_user() { $user = factory(User::class)->create(); $product = factory(Product::class)->create(['user_id' => $user->id]);

// kiểm tra foreignkey có giống nhau không
$this->assertEquals('user_id', $product->user()->getForeignKey());

 // kiểm tra instance BelongsTo
 $this->assertInstanceOf(BelongsTo::class, $product->user());

}
phần này e dùng getForeignKey không được phải dùng getForeignKeyName

0
thg 12 24, 2019 7:18 SA

oh. Cám ơn Đức.

+1
thg 12 24, 2019 6:57 SA

Chào bạn,

Qua những mô tả của bạn thì mình nghĩ tới hướng của mình như sau:

  • Các phần frontend ta sẽ tách biệt hẳn so với backend và giao tiếp với backend qua API.
  • Mỗi frontend và backend bạn setup riêng như 1 project độc lập (không nên nhét chung cả vào 1 file docker-compose vì như thế sau này file docker-compose trông sẽ dài

Ví dụ cấu trúc folder như sau:

- /database (folder để lưu trữ database, dùng cho backend, để mount từ bên ngoài vào trong container, xem bài số 6 của mình để hiểu hơn)
- backend.docker-compose.yml (file cấu hình backend Laravel)
- frontend1.docker-compose.yml (file cấu hình frontend thứ nhất)
- ....

Hi vọng giúp được bạn 😄

0
Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí