I've took a look at the PHP script behind my father website which has been built by a hired programmer. Now, I'm not thinking that I'm better than him, but I think its technique might not be the best.
我查看了我父亲网站背后的PHP脚本，这个脚本是由一个雇佣的程序员构建的。现在，我并不认为我比他强，但我认为它的技术可能不是最好的。
The website has dynamic page body, in the meaning that my dad can, via a specific admin page, modify the HTML content of most of the webpages in the website. Right now it's made via database: the pages are all stored in the database and every request deals with a query that fetches the page from the database and implement it.
网站具有动态页面主体，这意味着我的父亲可以通过一个特定的管理页面修改网站上大多数网页的HTML内容。现在它是通过数据库生成的:页面都存储在数据库中，每个请求都处理一个查询，该查询从数据库获取页面并实现它。
Now, I think this way is very bad mostly because it requires (even if not that expensive if cached) an additional query to the database. Wouldn't it be more efficient to store the pages as HTML files and then just modify the file itself when required? In this way the editing of the file, I think, is faster, and the loading of the content of an html file per request is a lot easier and faster than perform a query.
现在，我认为这种方法非常糟糕，主要是因为它需要(即使不那么昂贵)对数据库进行额外的查询。将页面存储为HTML文件，然后在需要时修改文件本身，难道不是更有效吗?通过这种方式，我认为文件的编辑速度更快，而且每个请求加载html文件的内容要比执行查询容易得多，也快得多。
Is it? Is there any other (more efficient) way to handling this situation?
是吗?有没有其他(更有效的)方法来处理这种情况?
5 个解决方案
#1
1
There are several good reasons why a CMS should use a Database to store/fetch the dynamic content. Just as there are several reasons why you might prefer not to rely on a DB.
CMS应该使用数据库存储/获取动态内容的原因有很多。正如您可能不喜欢依赖DB有几个原因一样。
-
Pro Db:
箴Db。
-
Security: It's an obvious, and slightly ambivalent argument, but nonetheless. If you decide to store your content as separate files on your server, they'll need to be stored in a directory that doesn't allow public access. If not, users might be able to access the chunks of your site separatly, which comes across as unprofessional.
People with ignoble intentions will have an easy time altering your site's content, too. Of course, there are many ways to prevent this, and increase overall security. Database systems, when left to their own devices, aren't exactly safe either, but provide an extra obstacle to hackers with minimal effort.
note: The security argument stands, or falls with how well your script filters out injection, and how secure you set up your server.安全性:这是一个明显的、有点矛盾的论点，但无论如何。如果您决定将内容存储为服务器上的独立文件，则需要将其存储在不允许公共访问的目录中。如果不是，用户可能可以单独访问站点的各个部分，这显得不专业。恶意用户也可以很容易地修改你的网站内容。当然，有很多方法可以防止这种情况，并提高整体安全性。数据库系统，如果任由它们自己的设备运行，也不是完全安全的，但只要付出最小的努力，就为黑客提供了额外的障碍。注意:安全性参数是不变的，或者与脚本过滤注入的能力以及设置服务器的安全性有关。
-
Disk usage. When using separate files to compose each requested page, The server has to access its HD on each request. Again, caching solves this issue to some extend, but it's easier and (in general) better to cache DB query results (performance wise). Either on your Database server, in PHP, or, better still, both.
磁盘使用情况。当使用单独的文件组成每个请求的页面时，服务器必须在每个请求*问它的HD。同样，缓存在一定程度上解决了这个问题，但是缓存DB查询结果(性能方面)更容易，而且(通常)更好。要么在数据库服务器上，要么在PHP中，或者更好的是，两者都在。
-
Logging. By this I mean: when you alter the content, a database driven CMS is a lot easier to manage. If you altered the content, and want to undo/rollback the changes, a DB is the easiest way to implement such a feature. Using HTML, you'll soon find yourself wading through tons of files called
site_menu_block_YYYY-mm-dd.html.backup. Even if this is done by a script, it'll almost certainly be slower than using a DB.日志记录。我的意思是:当您修改内容时，数据库驱动的CMS更容易管理。如果您修改了内容，并且想要撤消/回滚更改，DB是实现这样一个特性的最简单方法。使用HTML，您很快就会发现自己在浏览大量名为site_menu_block_yyyyyy -mm-dd. HTML .backup的文件。即使这是由脚本完成的，它几乎肯定比使用DB慢。
-
Translation: as vlzvl pointed out, if you're using static pages, you'll either end up with each page N times, once for each language. When altering the stylesheets, you'll then have to alter N files, too. Which is resource expensive. Alternatively, your scripts will parse an HTML template file for each request, and an XML file with the actual contents. This way you loose the SEO benefit of the HTML files, and cause extra server load and slow down your site.
翻译:正如vlzvl所指出的，如果您使用静态页面，您将得到每一页N次，每种语言一次。在修改样式表时，还需要修改N个文件。这是昂贵的资源。另外，脚本将解析每个请求的HTML模板文件，以及包含实际内容的XML文件。这样，您就失去了HTML文件的SEO优势，并导致额外的服务器负载和降低站点速度。
-
-
Pro HTML:
箴HTML。
- I can only give 1 solid pro argument here: it's a lot easier to get an SEO site this way. Just allow search engines to index the separate files. This does decrease the overall security of your CMS drastically .
- 在这里我只能给出一个可靠的专业论据:用这种方式获得SEO站点要容易得多。只允许搜索引擎索引单独的文件。这确实大大降低了CMS的整体安全性。
That said, I think I'm right in saying that all major CMS's use both methods, depending on what type of data they're dealing with. HTML headers, for example, are often partially stored as separate files, just like JS files and style-sheets.
也就是说，我认为所有主要的CMS都使用这两种方法，这取决于它们处理的数据类型。例如，HTML头通常部分存储为独立文件，就像JS文件和样式表一样。
#2
2
this is the question of the century :) there is no exact answer to this question. just performance tips. people are working to optimize page load times during recent 30 years.
这是本世纪的问题:)这个问题没有确切的答案。只是性能技巧。近30年来，人们致力于优化页面加载时间。
#3
2
No it isnt better to have fixed HTML pages under an hypothetical '/mypages' folder.
不，在假设的“/mypages”文件夹下有固定的HTML页面并不是更好的选择。
- What if the user wants about 500 contents in his webpage? he'll end up with 500 files.
- 如果用户在他的网页上想要大约500个内容呢?他会得到500份文件。
- Yeah sure, they'll be served faster but is that enough against the massive problems below?
- 是的，当然，他们的服务速度会更快，但这对下面的大问题来说就足够了吗?
- What about page translation? this would be nightmare in static html files.
- 页翻译呢?在静态html文件中，这将是一场噩梦。
- Pages are rendered that way because they're dynamic; that is, stuff can be "entered" by third parties/plugins (say) and applied into multiple contents at once; what about applying the same stuff into numerous HTMLs and then changing it again?
- 页面是这样呈现的，因为它们是动态的;也就是说，可以“输入”第三方/插件(比方说)，同时将其应用到多个内容中;如何将同样的材料应用到众多的HTMLs中，然后再改变它?
- What about if you want to change the < HEAD>*er and *< SCRIPT>**s loaded? you'll be forced to do that in all 500 contents in every change.
- 如果您想要修改< HEAD>*er和*< SCRIPT>* s加载怎么办?在每次更改中，您将*在所有500个内容中执行此操作。
- What about the PHP included in those .html files? This is not a reason if you're not putting PHP into this but in case of an included php file renamed/removed you'll need to change all files in a massive update.
- 那些.html文件中包含的PHP呢?如果不将PHP放入其中，这不是一个原因，但如果包含的PHP文件被重命名/删除，则需要在大规模更新中更改所有文件。
- Think of templates; the reason the modern CMS (or admin pages) are dynamic today is because they can change classes/styles etc. without affecting content itself. A single change to theme used or a single class would cause (again) a massive update.
- 认为模板;现代的CMS(或管理页面)之所以是动态的，是因为它们可以在不影响内容本身的情况下更改类/样式等。对使用的主题或单个类的单个更改将导致(再次)大规模更新。
- Database is files too, but run faster. If you worry about performance you can program the database to use caching (queries like SELECT data FROM content WHERE id=1) so the query is almost no-query in performance terms.
- 数据库也是文件，但运行速度更快。如果您担心性能问题，您可以对数据库进行编程以使用缓存(查询如从id=1的内容中选择数据)，这样查询在性能方面几乎是无查询的。
I can think of more.
我能想到更多。
#4
0
This all depends on the content. When you have much different content, like news it's easier to store the data inside a database for each newsentry and load the data into a template. But when you have single content (like a huge article or info page) you can use a HTML to store the data.
这完全取决于内容。当您有很多不同的内容时，比如news，就更容易为每个newsentry将数据存储在数据库中，并将数据加载到模板中。但是，当您只有一个内容(比如一篇巨大的文章或一个信息页面)时，您可以使用HTML来存储数据。
It also depends on if you want a multi-language page or not. You can surly create a multi-linugal page with only HTMLs. But here's the same as above. What content do you have. Much different entries or less same content?
它还取决于您是否需要多语言页面。您可以只用HTMLs创建一个多linugal页面。这和上面的一样。你有什么内容?不同的条目或更少的内容?
But, what I have done so far was I did both at the same time: When a client wanted a page with news script and multi-language and so on I created the page that the user can log in for news entries and store the news in different languages, but changes to other sites are made via HTML and there was for every language a different html file.
,但到目前为止我已经做了我所做的都在同一时间:当客户想要一个页面与新闻脚本和多语言等等我创建的页面,用户可以登录新闻条目,将消息存储在不同的语言,但其他网站更改都是通过HTML和每一个语言不同的HTML文件。
EDIT:
编辑:
It depends on the user, too. If the user don't know how to use HTML but wants to change the site hisself than the only available option is the option to give him an admin center to make changes. OR if you don't want give to much power to the user :D
这也取决于用户。如果用户不知道如何使用HTML，但是想要改变网站，那么他的选择就是给他一个管理中心来做出改变。或者如果你不想给用户太多的权力:D
#5
0
My opinion: Most CMS handle lots of DB accesses and load many files in order to compile one page that is eventually sent to a visitor. Still, for most sites there's no performance problem (i.e. most pages loading in < 1s). So I'd be surprised if you have a problem there, with just one single DB access. But for handling, why use a database, when your site doesn't really need it? I made a couple of sites for clients where I use one index.php that loads one menu file and one footer file that are the same for all pages, and inbetween it loads the individual selected html files. So in order to edit a page, you use any editor to open and edit the corresponding html. Very simple.
我的观点是:大多数CMS处理大量DB访问并加载许多文件，以便编译最终发送给访问者的一个页面。尽管如此，对于大多数站点来说，这并没有性能问题(即大多数页面在< 1 >中加载)。如果你有一个问题，只有一个DB访问，我会很惊讶。但是对于处理，为什么要使用数据库，而您的站点实际上并不需要它呢?我为客户做了几个网站，在那里我使用一个索引。加载一个菜单文件和一个页脚文件的php文件对所有页面都是相同的，并且在它之间加载单独选定的html文件。因此，为了编辑页面，您可以使用任何编辑器来打开和编辑相应的html。非常简单。
#1
1
There are several good reasons why a CMS should use a Database to store/fetch the dynamic content. Just as there are several reasons why you might prefer not to rely on a DB.
CMS应该使用数据库存储/获取动态内容的原因有很多。正如您可能不喜欢依赖DB有几个原因一样。
-
Pro Db:
箴Db。
-
Security: It's an obvious, and slightly ambivalent argument, but nonetheless. If you decide to store your content as separate files on your server, they'll need to be stored in a directory that doesn't allow public access. If not, users might be able to access the chunks of your site separatly, which comes across as unprofessional.
People with ignoble intentions will have an easy time altering your site's content, too. Of course, there are many ways to prevent this, and increase overall security. Database systems, when left to their own devices, aren't exactly safe either, but provide an extra obstacle to hackers with minimal effort.
note: The security argument stands, or falls with how well your script filters out injection, and how secure you set up your server.安全性:这是一个明显的、有点矛盾的论点，但无论如何。如果您决定将内容存储为服务器上的独立文件，则需要将其存储在不允许公共访问的目录中。如果不是，用户可能可以单独访问站点的各个部分，这显得不专业。恶意用户也可以很容易地修改你的网站内容。当然，有很多方法可以防止这种情况，并提高整体安全性。数据库系统，如果任由它们自己的设备运行，也不是完全安全的，但只要付出最小的努力，就为黑客提供了额外的障碍。注意:安全性参数是不变的，或者与脚本过滤注入的能力以及设置服务器的安全性有关。
-
Disk usage. When using separate files to compose each requested page, The server has to access its HD on each request. Again, caching solves this issue to some extend, but it's easier and (in general) better to cache DB query results (performance wise). Either on your Database server, in PHP, or, better still, both.
磁盘使用情况。当使用单独的文件组成每个请求的页面时，服务器必须在每个请求*问它的HD。同样，缓存在一定程度上解决了这个问题，但是缓存DB查询结果(性能方面)更容易，而且(通常)更好。要么在数据库服务器上，要么在PHP中，或者更好的是，两者都在。
-
Logging. By this I mean: when you alter the content, a database driven CMS is a lot easier to manage. If you altered the content, and want to undo/rollback the changes, a DB is the easiest way to implement such a feature. Using HTML, you'll soon find yourself wading through tons of files called
site_menu_block_YYYY-mm-dd.html.backup. Even if this is done by a script, it'll almost certainly be slower than using a DB.日志记录。我的意思是:当您修改内容时，数据库驱动的CMS更容易管理。如果您修改了内容，并且想要撤消/回滚更改，DB是实现这样一个特性的最简单方法。使用HTML，您很快就会发现自己在浏览大量名为site_menu_block_yyyyyy -mm-dd. HTML .backup的文件。即使这是由脚本完成的，它几乎肯定比使用DB慢。
-
Translation: as vlzvl pointed out, if you're using static pages, you'll either end up with each page N times, once for each language. When altering the stylesheets, you'll then have to alter N files, too. Which is resource expensive. Alternatively, your scripts will parse an HTML template file for each request, and an XML file with the actual contents. This way you loose the SEO benefit of the HTML files, and cause extra server load and slow down your site.
翻译:正如vlzvl所指出的，如果您使用静态页面，您将得到每一页N次，每种语言一次。在修改样式表时，还需要修改N个文件。这是昂贵的资源。另外，脚本将解析每个请求的HTML模板文件，以及包含实际内容的XML文件。这样，您就失去了HTML文件的SEO优势，并导致额外的服务器负载和降低站点速度。
-
-
Pro HTML:
箴HTML。
- I can only give 1 solid pro argument here: it's a lot easier to get an SEO site this way. Just allow search engines to index the separate files. This does decrease the overall security of your CMS drastically .
- 在这里我只能给出一个可靠的专业论据:用这种方式获得SEO站点要容易得多。只允许搜索引擎索引单独的文件。这确实大大降低了CMS的整体安全性。
That said, I think I'm right in saying that all major CMS's use both methods, depending on what type of data they're dealing with. HTML headers, for example, are often partially stored as separate files, just like JS files and style-sheets.
也就是说，我认为所有主要的CMS都使用这两种方法，这取决于它们处理的数据类型。例如，HTML头通常部分存储为独立文件，就像JS文件和样式表一样。
#2
2
this is the question of the century :) there is no exact answer to this question. just performance tips. people are working to optimize page load times during recent 30 years.
这是本世纪的问题:)这个问题没有确切的答案。只是性能技巧。近30年来，人们致力于优化页面加载时间。
#3
2
No it isnt better to have fixed HTML pages under an hypothetical '/mypages' folder.
不，在假设的“/mypages”文件夹下有固定的HTML页面并不是更好的选择。
- What if the user wants about 500 contents in his webpage? he'll end up with 500 files.
- 如果用户在他的网页上想要大约500个内容呢?他会得到500份文件。
- Yeah sure, they'll be served faster but is that enough against the massive problems below?
- 是的，当然，他们的服务速度会更快，但这对下面的大问题来说就足够了吗?
- What about page translation? this would be nightmare in static html files.
- 页翻译呢?在静态html文件中，这将是一场噩梦。
- Pages are rendered that way because they're dynamic; that is, stuff can be "entered" by third parties/plugins (say) and applied into multiple contents at once; what about applying the same stuff into numerous HTMLs and then changing it again?
- 页面是这样呈现的，因为它们是动态的;也就是说，可以“输入”第三方/插件(比方说)，同时将其应用到多个内容中;如何将同样的材料应用到众多的HTMLs中，然后再改变它?
- What about if you want to change the < HEAD>*er and *< SCRIPT>**s loaded? you'll be forced to do that in all 500 contents in every change.
- 如果您想要修改< HEAD>*er和*< SCRIPT>* s加载怎么办?在每次更改中，您将*在所有500个内容中执行此操作。
- What about the PHP included in those .html files? This is not a reason if you're not putting PHP into this but in case of an included php file renamed/removed you'll need to change all files in a massive update.
- 那些.html文件中包含的PHP呢?如果不将PHP放入其中，这不是一个原因，但如果包含的PHP文件被重命名/删除，则需要在大规模更新中更改所有文件。
- Think of templates; the reason the modern CMS (or admin pages) are dynamic today is because they can change classes/styles etc. without affecting content itself. A single change to theme used or a single class would cause (again) a massive update.
- 认为模板;现代的CMS(或管理页面)之所以是动态的，是因为它们可以在不影响内容本身的情况下更改类/样式等。对使用的主题或单个类的单个更改将导致(再次)大规模更新。
- Database is files too, but run faster. If you worry about performance you can program the database to use caching (queries like SELECT data FROM content WHERE id=1) so the query is almost no-query in performance terms.
- 数据库也是文件，但运行速度更快。如果您担心性能问题，您可以对数据库进行编程以使用缓存(查询如从id=1的内容中选择数据)，这样查询在性能方面几乎是无查询的。
I can think of more.
我能想到更多。
#4
0
This all depends on the content. When you have much different content, like news it's easier to store the data inside a database for each newsentry and load the data into a template. But when you have single content (like a huge article or info page) you can use a HTML to store the data.
这完全取决于内容。当您有很多不同的内容时，比如news，就更容易为每个newsentry将数据存储在数据库中，并将数据加载到模板中。但是，当您只有一个内容(比如一篇巨大的文章或一个信息页面)时，您可以使用HTML来存储数据。
It also depends on if you want a multi-language page or not. You can surly create a multi-linugal page with only HTMLs. But here's the same as above. What content do you have. Much different entries or less same content?
它还取决于您是否需要多语言页面。您可以只用HTMLs创建一个多linugal页面。这和上面的一样。你有什么内容?不同的条目或更少的内容?
But, what I have done so far was I did both at the same time: When a client wanted a page with news script and multi-language and so on I created the page that the user can log in for news entries and store the news in different languages, but changes to other sites are made via HTML and there was for every language a different html file.
,但到目前为止我已经做了我所做的都在同一时间:当客户想要一个页面与新闻脚本和多语言等等我创建的页面,用户可以登录新闻条目,将消息存储在不同的语言,但其他网站更改都是通过HTML和每一个语言不同的HTML文件。
EDIT:
编辑:
It depends on the user, too. If the user don't know how to use HTML but wants to change the site hisself than the only available option is the option to give him an admin center to make changes. OR if you don't want give to much power to the user :D
这也取决于用户。如果用户不知道如何使用HTML，但是想要改变网站，那么他的选择就是给他一个管理中心来做出改变。或者如果你不想给用户太多的权力:D
#5
0
My opinion: Most CMS handle lots of DB accesses and load many files in order to compile one page that is eventually sent to a visitor. Still, for most sites there's no performance problem (i.e. most pages loading in < 1s). So I'd be surprised if you have a problem there, with just one single DB access. But for handling, why use a database, when your site doesn't really need it? I made a couple of sites for clients where I use one index.php that loads one menu file and one footer file that are the same for all pages, and inbetween it loads the individual selected html files. So in order to edit a page, you use any editor to open and edit the corresponding html. Very simple.
我的观点是:大多数CMS处理大量DB访问并加载许多文件，以便编译最终发送给访问者的一个页面。尽管如此，对于大多数站点来说，这并没有性能问题(即大多数页面在< 1 >中加载)。如果你有一个问题，只有一个DB访问，我会很惊讶。但是对于处理，为什么要使用数据库，而您的站点实际上并不需要它呢?我为客户做了几个网站，在那里我使用一个索引。加载一个菜单文件和一个页脚文件的php文件对所有页面都是相同的，并且在它之间加载单独选定的html文件。因此，为了编辑页面，您可以使用任何编辑器来打开和编辑相应的html。非常简单。