2012-03-07 34 views
5

Tôi đang học lập trình web-centric bằng cách viết cho mình một blog, sử dụng PHP với một cơ sở dữ liệu MySQL backend. Điều này sẽ thay thế blog hiện tại của tôi (Drupal).Lưu trữ bài đăng trong cơ sở dữ liệu hoặc tệp?

Tôi đã quyết định rằng một post nên chứa một số dữ liệu: id, userID, title, content, time-posted. Điều đó làm cho một lược đồ tốt đẹp cho một bảng cơ sở dữ liệu. Tôi đang gặp sự cố khi quyết định cách tôi muốn sắp xếp lưu trữ content.

tôi có thể một trong hai:

  1. Sử dụng một hệ thống tập tin dựa trên. Bảng cơ sở dữ liệu content sau đó sẽ là một URL đến tệp được định vị cục bộ, sau đó tôi sẽ đọc, định dạng và hiển thị.
  2. Lưu toàn bộ nội dung của bài đăng trong content, tức là đặt nó vào cơ sở dữ liệu.

Nếu tôi đi với (1), tìm kiếm các nội dung của bài viết sẽ là hơi có vấn đề - Tôi muốn được giới hạn trong siêu dữ liệu tìm kiếm, hoặc tôi sẽ phải đọc các nội dung của mỗi tập tin khi tìm kiếm (mặc dù tôi không biết có bao nhiêu vấn đề sẽ xảy ra - grep -ir "string" . không phải là quá chậm ...). Tuy nhiên, hình ảnh (nếu có) sẽ được tham chiếu bởi URL, do đó, tham chiếu content ít nhất sẽ là phương pháp nhất quán nội bộ và tôi muốn dễ dàng có thể sử dụng lại nội dung, vì các tệp văn bản rất dễ làm việc, so với tệp cơ sở dữ liệu SQL.

Đi với (2), tuy nhiên, tôi có thể sử dụng số longtext. content sau đó sẽ cần phải được khử trùng trước khi tôi cố gắng để đưa nó vào tuple, và tôi bị giới hạn bởi kích thước (mặc dù, nó không chắc rằng tôi muốn viết một bài đăng blog 4GB;). Tìm kiếm sẽ dễ dàng.

Tôi không (hiện tại) xem cách nào sẽ (a) dễ triển khai hơn, (b) dễ dàng hơn để sống.

Tôi nên đi theo cách nào/thông thường được thực hiện như thế nào? Bất kỳ ưu/khuyết điểm nào khác cho (1) hoặc (2) sẽ được đánh giá cao.

+0

lập chỉ mục, v.v ... nếu bạn có cơ sở dữ liệu, bạn có thể lưu trữ dữ liệu trong nhiều bảng và liên kết chúng với khóa ngoài, v.v. – dee

Trả lời

4

Đối với 'thế hệ hiện tại', việc triển khai cơ sở dữ liệu là đặt cược an toàn nhất của bạn. Như bạn đã đề cập, nó khá chuẩn, và bạn vạch ra tất cả những thứ thú vị. Hầu hết các cá thể SQL có một tìm kiếm FULLTEXT (hoặc tương đương) khá mạnh. Có thể bạn sẽ có nhiều kiến ​​trúc để viết giữa hai thứ mà bạn vạch ra, đặc biệt nếu bạn muốn một cái có tính chẵn lẻ của tính năng kia.

Công nghệ tiên tiến là cửa hàng khóa/giá trị, thường được gọi là NoSQL. Với điều này, bạn có thể lưu trữ nội dung và siêu dữ liệu của mình thành từng tài liệu riêng biệt, nhưng theo cách có cấu trúc giúp tìm kiếm và truy xuất nhanh chóng. Một số động cơ NoSQL phổ biến là mongo, CouchDBredis (trong số các công cụ khác).

Cuối cùng, điều này tùy thuộc vào sở thích cá nhân, cùng với một số cân nhắc về trường hợp sử dụng. Bạn đã không thực sự phác thảo những gì quan trọng đối với bạn như xa như tiện nghi và ứng dụng của bạn. Bất kỳ một trong số này sẽ chỉ tốt cho một blog cá nhân hoặc phát triển. Xây dựng toàn bộ nền tảng với nhiều cộng tác viên là một cuộc trò chuyện khác.

1

13 năm trước tôi đã thử tùy chọn 1 của bạn (có tệp bên ngoài cho nội dung văn bản) - không phải bằng blog, nhưng với CMS.Và tôi đã kết thúc trong việc đẩy tất cả trở lại vào cơ sở dữ liệu để xử lý dễ dàng hơn. Việc thay thế toàn cầu trên cơ sở dữ liệu dễ dàng hơn nhiều so với mức tệp văn bản. Với số lượng lớn bài đăng mà bạn gặp phải với kích thước thư mục và tốc độ truy cập, hoặc bạn phải quản lý các sơ đồ thư mục con, v.v. Chỉ để tiếp cận cơ sở dữ liệu - Có một số công cụ giúp cuộc sống của bạn dễ dàng hơn với tệp văn bản Chức năng mysql, nhưng với một máy khách dòng lệnh như mysql và mysqldump bạn có thể dễ dàng trích xuất bất kỳ văn bản nào sang mức hệ thống tệp, làm việc trên chúng với các công cụ tiêu chuẩn và tải lại chúng vào cơ sở dữ liệu. Những gì mysql thực sự thiếu được xây dựng trong hỗ trợ cho regex tìm kiếm/thay thế, nhưng ngay cả đối với bạn sẽ tìm thấy một bản vá nếu bạn sẵn sàng biên dịch lại mysql.

Các vấn đề liên quan