Tôi muốn phát huy thế mạnh của từng hệ thống.
Logic tổng hợp, nối và lọc rõ ràng thuộc về lớp dữ liệu. Nó nhanh hơn, không chỉ bởi vì hầu hết các công cụ DB có hơn 10 năm tối ưu hóa để thực hiện điều đó, mà bạn giảm thiểu dữ liệu được chuyển giữa DB và máy chủ web của mình.
Mặt khác, hầu hết các nền tảng DB mà tôi đã sử dụng có chức năng rất kém để làm việc với các giá trị riêng lẻ. Những thứ như định dạng ngày tháng và thao tác chuỗi chỉ cần thực hiện trong SQL, tốt hơn là bạn nên thực hiện công việc đó trong PHP.
Về cơ bản, hãy sử dụng từng hệ thống cho những gì nó được xây dựng để làm.
Về khả năng bảo trì, miễn là sự phân chia giữa những gì xảy ra ở đâu là rõ ràng, thì việc tách chúng thành các loại logic sẽ không gây ra nhiều vấn đề và chắc chắn là không đủ để tìm ra lợi ích. Theo quan điểm của tôi, sự rõ ràng và khả năng bảo trì của mã liên quan đến tính nhất quán hơn là đặt tất cả logic vào một chỗ.
Re:ví dụ cụ thể ...
-
Tôi biết đây không phải là những gì bạn đang đề cập nhưng ngày gần như là một trường hợp đặc biệt. Bạn muốn đảm bảo rằng tất cả các ngày do hệ thống tạo ra đều được tạo trên máy chủ web HOẶC cơ sở dữ liệu. Làm theo cách khác sẽ gây ra một số lỗi ngấm ngầm nếu máy chủ db và máy chủ web đã từng được định cấu hình cho các múi giờ khác nhau (tôi đã thấy điều này xảy ra). Hãy tưởng tượng, chẳng hạn, bạn có
createdDatevới mặc định làgetDate()được áp dụng trên insert bởi DB . Nếu bạn định chèn một bản ghi thì hãy sử dụng ngày được tạo trong PHP (ví dụ:date("Y-m-d", time() - 3600), chọn các bản ghi được tạo trong giờ trước, bạn có thể không nhận được những gì bạn mong đợi. Đối với lớp nào bạn nên thực hiện việc này, tôi sẽ ưu tiên cho DB, như trong ví dụ, nó cho phép bạn sử dụng các giá trị mặc định của cột. -
Đối với hầu hết các ứng dụng, tôi sẽ làm điều này bằng PHP. Việc kết hợp tên và họ nghe có vẻ đơn giản cho đến khi bạn nhận ra đôi khi bạn cũng cần những lời chào, chức danh và chữ viết tắt ở giữa. Thêm vào đó, bạn gần như chắc chắn sẽ rơi vào tình huống mà bạn muốn có tên, họ của người dùng VÀ kết hợp cách chào + tên + họ. Kết hợp chúng với phía DB có nghĩa là bạn sẽ di chuyển nhiều dữ liệu hơn, mặc dù thực sự, nó khá nhỏ.
-
Phụ thuộc. Như trên, nếu bạn muốn sử dụng chúng một cách riêng biệt, tốt hơn hết bạn nên kéo chúng ra một cách riêng biệt và ghép nối khi cần thiết. Điều đó nói rằng, trừ khi các tập dữ liệu mà bạn đang xử lý là rất lớn, có thể có các yếu tố khác (như bạn đề cập, khả năng bảo trì) có ảnh hưởng nhiều hơn.
Một vài quy tắc chung:
- Việc tạo id gia tăng sẽ diễn ra trong DB.
- Về mặt cá nhân, tôi thích DB áp dụng mặc định của mình.
- Khi chọn, DB sẽ thực hiện bất kỳ điều gì làm giảm số lượng bản ghi.
- Việc làm giảm kích thước của phía DB tập dữ liệu thường tốt (như với ví dụ về chuỗi ở trên).
- Và như bạn nói; thứ tự, tổng hợp, truy vấn phụ, liên kết, v.v. phải luôn ở phía DB.
- Ngoài ra, chúng tôi chưa nói về chúng nhưng các trình kích hoạt thường không tốt / cần thiết.
Có một số đánh đổi cốt lõi mà bạn phải đối mặt ở đây và số dư thực sự phụ thuộc vào ứng dụng của bạn.
Một số điều chắc chắn nên-mọi-lúc-luôn được thực hiện trong SQL. Loại trừ một số trường hợp ngoại lệ (như ngày tháng) đối với nhiều tác vụ SQL có thể rất rắc rối và có thể khiến bạn suy nghĩ về logic ở những nơi khác. Khi tìm kiếm cơ sở mã của bạn cho các tham chiếu đến một cột cụ thể (ví dụ), nó là dễ bỏ sót những thứ có trong một dạng xem hoặc thủ tục được lưu trữ.
Hiệu suất luôn là một yếu tố cần cân nhắc, nhưng tùy thuộc vào ứng dụng của bạn và ví dụ cụ thể, có thể không lớn. Mối quan tâm của bạn về khả năng bảo trì và có lẽ rất hợp lệ và một số lợi ích về hiệu suất mà tôi đã đề cập là rất nhỏ, vì vậy hãy cẩn thận với việc tối ưu hóa quá sớm.
Ngoài ra, nếu các hệ thống khác đang truy cập trực tiếp vào DB (ví dụ:để báo cáo hoặc nhập / xuất), bạn sẽ được hưởng lợi từ việc có nhiều logic hơn trong DB. Ví dụ:nếu bạn muốn nhập trực tiếp người dùng từ một nguồn dữ liệu khác, chức năng xác thực email có thể sử dụng lại được sẽ được triển khai trong SQL.
Câu trả lời ngắn gọn:nó phụ thuộc. :)
