我正在通过使用 PHP 和 MySQL 数据库后端编写自己的博客来学习以 Web 为中心的编程。这应该取代我当前的(基于 Drupal 的)博客。
我决定一个post应该包含一些数据:id, userID, title, 内容，发布时间。这为数据库表创建了一个很好的模式。不过，我在决定如何组织 content 的存储时遇到了问题。
我可以:
- 使用基于文件的系统。数据库表
content将成为本地文件的 URL，然后我将读取、格式化和显示该文件。 - 将帖子的全部内容存储在
content中，即将其放入数据库。
如果我选择 (1)，搜索帖子的内容会有点问题 - 我将仅限于元数据搜索，或者我必须在搜索时读取每个文件的内容(虽然我没有知道问题有多大 - grep -ir "string". 不是太慢...)。但是，图像(如果有的话)将由 URL 引用，因此引用 content 至少是一种内部一致的方法，而且我很容易能够重用内容，因为与 SQL 数据库文件相比，文本文件非常容易处理。
不过，对于 (2)，我可以使用 longtext . content 然后需要在我尝试将其放入元组之前进行清理，而且我受到大小的限制(尽管我不太可能写一篇 4GB 的博客文章；)。搜索会很容易。
我(目前)看不出哪种方式 (a) 更容易实现，(b) 更容易接受。
我应该走哪条路/这通常是怎么做的？ (1) 或 (2) 的任何进一步优点/缺点将不胜感激。
最佳答案
对于“当前这一代”，实现数据库几乎是最安全的选择。正如您提到的，它非常标准，并且您概述了所有有趣的内容。大多数 SQL 实例都有相当强大的 FULLTEXT(或等效)搜索。 在您概述的两者之间，您可能需要编写同样多的架构，特别是如果您希望其中一个具有另一个的功能对等性。
新兴技术是键/值存储，通常称为NoSQL .有了它，您可以将您的内容和元数据存储到单独的单独文档中，但以结构化的方式进行搜索和检索非常快。一些常见的 NoSQL 引擎是 mongo , CouchDB , 和 redis (除其他外)。
最终这取决于个人偏好以及一些用例注意事项。就便利性和应用程序而言，您并没有真正概述什么对您很重要。其中任何一个都适合个人或开发博客。与多个贡献者一起构建整个平台是另一回事。
关于php - 将帖子正文存储在数据库或文件中？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9607494/