CODEWITHSUNDEEP
phpmysqldatabasefile
sanjeev mk
sanjeev mk

Reputation: 4336

Effective data storage when there is no limit on data size

I have a PHP application that takes objects from users, and stores them on a server. Similar to an upload-download service. The object could vary from just a string of text,to any kind of media object like a movie, songs etc. Even if a simple text is sent, the size of the text sent could be big (probably an entire ebook). At present, the way I'm doing this is, write all these data to files, because files don't impose a size limit.

Edit: To clarify, I'm looking for a generic and efficient way for storing data, no matter what the format. For example, a user could send the string, "Hi, I am XYZ". I can store this using file operations like "fopen", "fwrite". If a user sends an MP3 file, I can again use "fwrite" and the data of the file will be written as is, and the MP3 format is not disturbed. This works perfectly at present, no issues. So "fwrite" is my generic interface here.

My question: Is there some better, efficient way to do this?

Thanking you for your help!

Upvotes: 2

Views: 123

Answers (2)

Ziumin
Ziumin

Reputation: 4860

Storing files in a file system is not the bad way until your file system has no limits on files per directory count, on the file size. It can be also hard to sync it over a number of your servers. In that case of limitations you can use some kind of virtual fs (like mongo gridFS)

Upvotes: 0

Gordon Linoff
Gordon Linoff

Reputation: 1270443

The answer to this question is rather complicated. You can definitely store such objects in the databases as LONGBLOB objects -- unless you are getting into the realm of feature length movies (the size limit is 32 bits).

A more important question is how you are getting the objects back to the user. A "blob" object is not going to give you much flexibility in returning the results (it comes from a query in a single row). Reading from a file system might give more flexibility (such as retrieving part of a text file to see the contents).

Another issue is backup and recovery. Storing the objects in the database will greatly increase the database size, requiring that much more time to restore a database. In the event of a problem, you might be happy to have the database back (users can see what objets they have) before they can actually access the objects.

On the other hand, it might be convenient to have a single image of the database and objects, for moving around to, say, a backup server. Or, if you are using replication to keep multiple versions in sync, storing everything in the database gives this for free (assuming you have a high bandwidth connection between the two servers).

Personally, I tend to think that such objects are better suited for the file system. That does require a somewhat more complicated API for the application, which has to retrieve data from two different places.

Upvotes: 2

Related Questions