I searched about the topic (which faster filesystem or database), but I always got the same answers which is: using filesystem as storage of data.
However, what I'm asking for is which faster when you just click a link pointing to a PHP file contains Include(file.html) or contains a mySQL query (Select content From table Where..).
PS: Both content from "file.html" and from the query
Thanks
" are the same.
Reading a static file is nearly always faster than running an SQL query that returns the same information.
The reason that developers use a database is to support data that isn't static. That is, data changes in complex ways. Sometimes it's only individual records changing.
In many web sites, if you try to replace the whole static html file every time one thing in it changes, you will find that you can't do that fast enough to keep up with the rate of changes.
But it may be that a given web page view doesn't need all the data in that static file. It only needs a small subset, related to the current user who is viewing the web page. Or related to recent changes. Reading a limited subset of data using SQL is much faster than reading a huge static file.
For example: Suppose your website is about concert tickets. It records every concert, and every attendee, and every ticket sale. Should that go into one huge static file to be included by every PHP request? What if a user only wants to view the information about their ticket purchase for one upcoming concert? It would be wasteful to read the whole file that contains both upcoming concerts as well as past records of hundreds of concerts and millions of ticket sales.
I disagree. Sometimes.
The performance difference is not enough to worry about. But here is some discussion...
The real metric is how many times you touch the disk.
Here's a comparison where "database" wins:
For fetching an entire file, think of it as 2 steps: One to touch the disk to look in the directory to find the file and "open" it, then another to fetch the data from the file.
For fetching some a chunk of data from a database that is already open, the first step is not needed. The second step may still exist -- fetching the data from somewhere in the database's structures.
Here's a case where "file" wins:
The data is broken up into multiple rows and possibly multiple tables. And the fetching needs to gather the stuff and put it together. Several disk hits may be needed, or even several million disk hits. Hence, the database is slower.
I will argue that a common case has a different reason for deciding: You want to show an <img ...> on a web page.
There are at least 3 ways to store an image in a database; you would need to pick a way, then code for it. This is programmer overhead.
Letting the web server simply deliver the image via <img src=foo/bar/xyz.jpg> requires nearly zero programmer work. And it may actually involve fewer disk hits. This is because large BLOBs tend to be somewhat scattered in the database structure. Yeah, the filesystem may also be scattering the jpg around.
Oh, another point. If you are talking about web stuff, then the "statelessness" of web servers means (usually) that the database is not open. This adds a small fraction of a second of delay. If you will be using the database for other stuff, then this may not matter.
The database reads its data also from a filesystem, where he stores the data.
so it will be slower as when you read them directly.
Databases are faster when many people try to access data and write them.
