1. Trong bài giảng, tôi ho rất nhiều. Tôi hy vọng các bạn chú ý đến sức khỏe của người hướng dẫn, bao gồm cả bệnh ho. Chẳng phải học sinh sẽ coi sức khỏe của mình là ưu tiên cao hơn bài giảng của giảng viên sao? 2. Giải thích vòng vo quá nên thấy khó hiểu quá. Ví dụ: khi = trong mệnh đề Where trả về nhiều kết quả, truy vấn con một hàng sẽ trả về nhiều hơn một hàng. Tôi ước gì bạn có thể xác định chính xác lỗi, nhưng bạn nói rằng sẽ tốt hơn nếu sử dụng mệnh đề in. 3. Vì đây là bài giảng mô hình hóa nên tôi hy vọng sẽ rõ ràng hơn về cách đặt tên bảng và tiêu chí xác định cột, đồng thời sẽ là bài giảng có thể sử dụng được trong những tình huống phức tạp hơn như được sử dụng trong thực tế . Ví dụ: bạn có thể thấy rõ đó là bảng DB nhưng bạn thêm 't_' thông tin, nhưng chìa khóa có cần thiết không?), v.v. Nếu tiêu chuẩn riêng của người hướng dẫn về việc quyết định tên bảng đã rõ ràng, tôi nghĩ người nghe sẽ nghĩ, "Ồ, người hướng dẫn này đã đưa ra lựa chọn này dựa trên những tiêu chuẩn này." 4. Khi nói đến lập mô hình cơ sở dữ liệu, tại sao bạn nên lập mô hình? Trong thực tế, vì một số lý do khác ngoài lý do “vì đây là cách nó được thực hiện trong thực tế”, các cột này được đặt trong thực tế, kích thước cột dựa trên A, loại cột dựa trên B, dịch vụ nào, môi trường nào? Tôi rất tiếc rằng nếu mô hình được giải thích chi tiết và thực hành, học sinh sẽ có chỗ để suy nghĩ về cách giải quyết vấn đề và lẽ ra có thể cải thiện được khả năng của mình. kỹ năng hơn nữa. - Tuy nhiên, tôi cảm thấy như mình đang học mô hình cơ sở dữ liệu từ góc độ của người mới bắt đầu, vì vậy tôi lắng nghe cẩn thận và nghĩ rằng mình đang học lại lớp chuyên ngành của mình ở trường. - Biết cách tiếp cận giải pháp khi giải các bài toán SQL cũng là một điều tốt. - Tôi cũng rất vui khi tìm hiểu về các ví dụ về miền thương mại. Cảm ơn bạn vì bài giảng tuyệt vời.