Sho*_*hoe 6 html php database file
我看了一下我父亲网站背后的PHP脚本,该脚本是由一位雇佣的程序员构建的.现在,我不认为我比他好,但我认为它的技术可能不是最好的.
该网站具有动态页面主体,意思是我的父亲可以通过特定的管理页面修改网站中大多数网页的HTML内容.现在它是通过数据库创建的:页面都存储在数据库中,每个请求都处理一个从数据库中获取页面并实现它的查询.
现在,我认为这种方式非常糟糕,主要是因为它需要(即使没有那么昂贵,如果缓存)对数据库的额外查询.将页面存储为HTML文件然后只在需要时修改文件本身不是更有效吗？通过这种方式,我认为编辑文件的速度更快,每个请求加载html文件的内容比执行查询要容易得多,速度也快.
是吗？有没有其他(更有效)的方法来处理这种情况？
CMS 应使用数据库来存储/获取动态内容有几个很好的理由。正如您可能不愿意依赖数据库的原因有多种一样。
专业数据库：
安全性：这是一个显而易见的、有点矛盾的论点，但尽管如此。如果您决定将内容作为单独的文件存储在服务器上，则它们需要存储在不允许公共访问的目录中。如果没有，用户可能能够单独访问您网站的各个部分，这会显得不专业。
怀有卑鄙意图的人也可以轻松地更改您网站的内容。当然，有很多方法可以防止这种情况发生，并提高整体安全性。数据库系统如果留给自己的设备使用，也并不完全安全，反而会以最小的努力为黑客提供额外的障碍。
注意：安全性参数的好坏取决于您的脚本过滤注入的能力以及您设置服务器的安全程度。
磁盘使用情况。当使用单独的文件来组成每个请求的页面时，服务器必须在每个请求上访问其 HD。同样，缓存在某种程度上解决了这个问题，但是缓存数据库查询结果更容易并且（通常）更好（性能方面）。要么在数据库服务器上，要么在 PHP 中，或者更好的是，两者都可以。
记录。我的意思是：当您更改内容时，数据库驱动的 CMS 更容易管理。如果您更改了内容，并且想要撤消/回滚更改，那么数据库是实现此类功能的最简单方法。使用 HTML，您很快就会发现自己正在浏览大量名为site_menu_block_YYYY-mm-dd.html.backup. 即使这是通过脚本完成的，它几乎肯定会比使用数据库慢。
翻译：正如 vlzvl 指出的那样，如果您使用静态页面，那么您要么每个页面出现 N 次，每种语言一次。当更改样式表时，您还必须更改 N 个文件。这是资源昂贵的。或者，您的脚本将为每个请求解析一个 HTML 模板文件，以及一个包含实际内容的 XML 文件。这样您就失去了 HTML 文件的 SEO 优势，并导致额外的服务器负载并降低您的网站速度。
专业 HTML：
也就是说，我认为所有主要 CMS 都使用这两种方法，具体取决于它们处理的数据类型，这是正确的。例如，HTML 标头通常部分存储为单独的文件，就像 JS 文件和样式表一样。