server performance mysql vs file_put_contents

[ggalan]

how much load am i putting on the server using "file_put_contents" if i have a few hundred clients concurrent on the server?
i need the server to create a json file and im considering using mysql instead as a format for the front end to get its data.
any thoughts please, thank you.

[djr33]

There are a number of factors that differ between the two options. I'm not sure of an exact answer, but there is a bigger thing to consider.

In the big picture, it entirely depends on how you are storing and accessing the data. Databases are specifically designed to be flexible and searchable, and they allow for easy access to the data in many ways. Flat files don't-- they just store a chunk of text and is only accessible as a chunk.

The question then is whether you want chunks of text or if you want organized, searchable, easily manipulated data.

If you want the more flexible option, then clearly a database is the answer. There's no question about that.


If you do just want to store and access chunks of data at a time (like in a text file), that's when you'd need to ask the question about which is more efficient.


In short:
Very very rarely are databases not efficient. Text files often can be inefficient because you don't want to save or access the whole file at one time and that means you must manipulate extra data in the file every time you want to do that.

If you don't work the system too hard, you may not notice a difference, but with lots of users, the database will usually be more efficient, unless it's just chunks of data you're saving.


One clear example of a case where files are better is for storing images. Rather than storing the images as data in the database, there are a number of reasons that storing them as image files is better.



Another thing to consider is whether one text file equals one database entry. If you have many lines in a text file that are stored independently in a database, then retrieving that one time is equivalent to many database queries. You'll get ALL of the data with one operation using the file, so if you DO want to retrieve all of the information every time, in some sense it's more efficient. But usually there are more practical reasons for what size chunks of data you want.

[ggalan]

in the end i do need that json file for the front end.
there are many small json files, so the write would be slightly more than 1 dB entry.

not having a dB would make the code a lot more minimal and easier to maintain but i am interested in performance in the end.
so if there are lots of re-writes would you recomend a db?

i was just not very sure about making txt files vs dB entries, your point of view was very clear.

1 question

One clear example of a case where files are better is for storing images. Rather than storing the images as data in the database, there are a number of reasons that storing them as image files is better.

what did you mean by this?

[djr33]

About the images: I was trying to give one example where flat files (text files) ARE better than a database. There are not very many examples, but I thought that might help you understand one situation (and from that, the type of situation) where flat files are good.


Yes, if you need to quickly access and rewrite the information, a database is probably best.

And no, I don't think you'd actually have more or more complex code with a database. Databases are a little harder to learn (mostly just MORE to learn), and they require configuring a database to use. After that, they can often be easier and sometimes even less code to use.


It sounds to me like either option would probably work for you in this case. But databases are the safer option.


The real summary of the difference is organization: flat files are simple and have no system of organization; databases are a little more complicated and are very well organized.

Do you need organization at all? If so, use databases.

[ggalan]

i think in terms of organization the flat files are fine
but
in terms of performance and reliability the dB sounds like a more robust solution