1

我总是有一个难题：对于记录，我可以使用列图像（tinyint），如果该记录有图像，则为真，如果没有，则为假。

我也不能将该信息放入数据库中，并且在我的代码中我“窥探”磁盘文件系统检查图像是否存在。

当然，两者都给出相同的结果。在数据库中意味着将图像状态与磁盘上的真实图像分开维护，这意味着更难编程并且更容易出错（磁盘图像不再存在，在数据库中，列图像上的记录是真实的）。

所以我通常使用磁盘检查。但我突然想到，这可能会对磁盘访问造成严重影响。我知道数据库检查必须更快，无论如何我必须从数据库中取出记录。但是使用文件系统寻找图像是否像我遇到的那样糟糕？

4

3 回答 3

2

将其存储在数据库中的优点：

  • 您可以创建查询来回答诸如“给我所有没有图像的对象”之类的问题
  • 它的速度要快得多，因为您不必触摸磁盘

我看不出只将它存储在磁盘上的优点。使用具有“单一职责”的模式，这意味着您的代码中只有一个地方保存、更新、删除图像。在这个地方你更新文件和数据库。这样做，它不太容易出错。

反过来说：如果这使您的应用程序容易出错，您应该检查您的架构。

于 2011-07-20T14:09:40.730 回答
2

在我看来，检查磁盘是一种浪费，也是一种不好的做法。数据库应该持有这个，因为：

  • 它要快得多。
  • 未检索到所需记录的磁盘查找应被视为错误（当然，也可以优雅地处理）。

维护列不应该大惊小怪，因为无论如何都要维护文件名，对吗？因此，当文件名更新时，此列也应相应更新。

于 2011-07-20T14:04:27.810 回答
1

图像更可能存在还是更可能不存在？如果您查看该文件是否存在，您会一直使用该文件吗？

如果两者的答案都是“是”，那么请务必使用磁盘。如果您有理由相信它在绝大多数时间都存在，那么使用@file并处理 FALSE 返回（特别是因为 file_exists 可能存在跨平台实现问题）。我认为这不仅仅是足够的练习。

如果没有，那么您需要查看您的程序流程：

询问数据库——文件是否存在？

  • 是 = 获取文件。
    • 如果文件不是真的需要做一些假设文件存在
    • else fetch file => 文件获取成功了吗？（即使使用 DB 查询，您也在进行此检查）
      • 是 = 对文件做某事
      • no = 更新数据库并做一些没有文件的事情。
  • no = 在没有文件的情况下做某事。（文件存在何时更新？cron？）

如果您打算使用该文件，则必须检查该文件，如果数据库说它在那里，这意味着您可以使用数据库进行优化的唯一时间是在不需要文件本身的时候。

于 2011-07-20T14:23:14.590 回答