Figure 1: Conceptual Database Design

Figure 2: Logical Database Design

Figure 3: Physical Database Design

Figure 4: User Activity Diagram

Figure 5: User Set Schedule Activity Diagram
 Figure 6: Scheduler Activity Diagram

1. Tại sao lại chọn SQL mà không chọn NoSQL?

Ans:
- Việc xử lý transaction của SQL tốt hơn so với NoSQL.
- Database Normalization giảm thiểu sự dư thừa (redundancy), trùng lặp (duplicate) và
giá trị NULL của dữ liệu trong database.
Đồng thời, Database Normalization giúp bảo tính toàn vẹn của dữ liệu trong database
bằng cách loại bỏ các đặc điểm bất thường, không mong muốn xảy ra khi thực hiện
CRUD operations.
Tụi em tham khảo ở link này:
https://www.studytonight.com/dbms/database-normalization.php

2. Tại sao lại có 2 table news_website ?

Ans: Cái này trong quá trình chỉnh sửa thì tụi em chưa xóa 1 bảng news_website á
anh. Và chỉ có 1 table news_website để lưu các website mà system của mình hỗ trợ
crawl.

3. Nếu 2 bài news có trùng tên author với nhau thì làm sao phân biệt được đó là
cùng 1 author hay là 2 author trùng tên với nhau ?
Ans: Cái này mình phân biệt author qua author_id chứ đâu phải qua tên đâu anh.

4. Mối liên hệ giữa crawl_history và news là gì? Khi crawl data thì crawl_history
được lưu lại, vậy thì news sẽ được lưu lại như thế nào?
Ans:
- Mối liên hệ giữa crawl_history và news là N:M, tức 1 crawl_history sẽ chứa nhiều
news và 1 news có thể nằm trong nhiều crawl_history.
- Khi crawl data thì crawl_history sẽ được lưu lại trong database. Lúc này có bảng
contains_crawl_item sẽ chịu trách nhiệm lưu news cho crawl_history (bao gồm
news_id và crawl_history_id).

5. Tại sao table crawl_history lại cần updated_date?

Ans:
Vì tụi em đang tính việc là sẽ thêm 2 fields nữa ở crawl_history table là:
● ”crawl_file_url": Lưu download URL của file đã export ra trước đó và được lưu
trên Google Cloud Storage.
● “crawl_file_ type": Lưu type của export file đó.
Thì mình sẽ cập nhật 2 field này của crawl_history_table. Khi có request xuất ra JSON/
CSV file thì Backend sẽ check trong database là có crawl_file_url chưa; Nếu có thì lấy
trả về luôn, không thì phải thực hiện export function.
6. Trường option_field và option_value trong table crawl_filter_option có nghĩa là
gì? tại sao lại cần 2 field này? Nếu table này bị edit/delete/insert thì crawl_history
có bị ảnh hưởng hay không, ảnh hưởng như thế nào?
Ans:
- Table crawl_filter_option có 2 trường là option_field và option_value để lưu các
filter options và giá trị của nó mà người dùng thiết lập để tìm kiếm trên data mình
đã crawl về.
- Hai trường này có tác dụng khi người dùng xem lại lịch sử crawl thì sẽ biết được
là data crawl đó được filter theo những options nào (ví dụ: data được sort theo
cái gì hay được tìm kiếm dựa trên keyword gì, …)
- Tụi em không tính thay đổi trên crawl_filter_option á anh. Tại vì nếu thay đổi thì
crawl_history chắc chắn sẽ bị ảnh hưởng, tức data trong crawl_history sẽ không
còn chính xác đối với crawl_filter_option nữa. Việc cập nhật crawl_history table
theo crawl_filter_option table sẽ cost nhiều á anh.
7. Nếu có những user yêu cầu crawl giống nhau thì sao?
Ans:
- Nếu có request crawl giống nhau thì mình chỉ cần trả data về theo yêu cầu user
đó dựa trên database của mình thôi anh.

8. Tại sao id là cần tới VARCHAR(255)?

Ans:
- Đây là lỗi của tụi em. Sau khi tìm hiểu thì các id của các table chỉ nên có kiểu
VARCHAR(36) thôi. Tụi em làm dựa trên type UNIQUEIDENTIFIER của
Microsoft SQL Server.
Tụi em tham khảo ở đây ạ: https://www.dofactory.com/sql/uniqueidentifier

9. Yêu cầu coi lại, tại sao toàn là VARCHAR(255) ?

Ans:
- Đối với các id thì như câu trên tụi em sẽ chỉnh lại là VARCHAR(36).
- Đối với password thì tụi em chỉnh lại là VARCHAR(72) dựa trên độ dài của chuỗi
hash bằng bcrypt.
- Đối với các trường input từ user như option_value, option_field, email hay các
trường phụ thuộc vào việc crawl từ các trang web khác thì mình khó kiểm soát
được độ dài của chuỗi nên tụi em set VARCHAR(255) để có thể lưu được tối đa
dữ liệu có thể có ạ.

10. Lưu ý: User không cần login để sử dụng app của mình, nhưng user cần cung
cấp tài khoản để crawl về từ các trang web họ muốn.
Ans:
- Anh có thể giải thêm ý này được không ạ ? Ý là nếu không cần login thì mình sẽ
cho phép việc crawl những gì hay là không crawl luôn ạ. Tại vì function chính
của app mình là crawl á anh.
- Hiện tại trên database design của tụi em là crawl_history_table bắt buộc phải có
user_id, tức là yêu cầu phải login mới được crawl á anh.

11. Flow để schedule crawler của mình ở đâu? Mình lưu những cái mình cần
schedule ở đâu? cái gì sẽ là scheduler
Ans:
- Những cái mình cần schedule tụi em nghĩ là phải thêm 1 table:
crawl_schedule_setting chứa các attribute: interval_unit, interval_value,
news_website_id và user_id.
- Với flow để schedule crawler, tụi em tính dùng Cloud Scheduler và Cloud Run
trên GCP để chạy crawl. Flow sẽ bắt đầu với user nhập params trên frontend,
 gửi qua API. Từ API tụi em sẽ tạo task dựa trên parameter đó và gửi request tạo
crawl job để chạy Cloud Run function ở thời điểm và interval đã cho. Sau khi đã
chạy xong thì sẽ lưu dữ liệu vào database.
- Về cách bảo đảm Cloud Run function hoạt động ổn khi có nhiều request, thì tụi
em đang cân nhắc dùng load balancing cho crawler function và message queue
để queue task vào khi có request mới có được không anh? Tụi em đang không
chắc về nên bỏ message queue ở API hay cloud function?