Hello,
I will be starting a new project and I need to decide if I am going to save uploaded documents(pdf and jpgs) into a file system of the database. The general idea seem to be to save it to the file system. But I love the idea to not deal with directories and just select the document from a database table. From a keep it simple, seems to be the way to go. BUT I am very concern, about long term. What problems could come up, by having all the docuemnts in the database? Could it be a good idea to create a separate database just for the documents? Should I just keep the on the file system? I will be running on 2 machines. A web server on the DMZ and the mysql server in the internal network. If I save the files on the file systems, it means I have to ftp the files to the mysql server(If I take the file system route), and maybe I have the ftp them back to present them to the user.
Anyone with prev experience on this, let me know. So far, when I upload documents, they are on the same machine as the web server, so moving documents from one machine to another , was never a concern.
Thank you
saving images into file or database
Moderator: General Moderators
Re: saving images into file or database
Hi,
There are generally two polarised schools of thought - the "ah, that'll be all right" and the "no, oh my god no, that's what a file system is for" camp.
Really it comes down to performance and the thing that most affects this is the sheer number of files (equating to number of rows in the database) and how often/quickly you need them returned.
After all a filesystem is basically just a big database - albeit one highly optimised for the storage and retreval of files via a index structure rather than a generic relational database such as MySQL.
Storing files in MySQL is not technically difficult and there are a whole load of resources and tutorials showing you how to do it. You will of course have to handle the encoding/decoding, storing/finding and presentation (MIME types etc) yourself in code but again no big problem.
If your tables are indexed correctly, optimised and of a reasonable size then the seeking of files should be fairly quick.
But remember - doing an index search, loading the data into an array, processing (decoding or adding MIME headers) and then outputting will always be slower and much more process intensive than allowing the user to directly request the file from the filesystem via HTTP or just opening it yourself via PHP and streaming it out.
Have you maybe considered that? If your two servers can "see" each other then designate one the storage system. When files are uploaded get PHP to save them locally (on the designated storage server) or just in turn upload them to the storage server from the non-storage. When requesting a file the storage server just fopen()'s a file on it's local filesystem and the non-storage server does an fopen('http://my.storage.server/files/filename.whatever') instead.
Anyway - those are my confused and rambling thoughts on the matter.
Good luck with whichever implementation you go for.
Regards,
Dave.
There are generally two polarised schools of thought - the "ah, that'll be all right" and the "no, oh my god no, that's what a file system is for" camp.
Really it comes down to performance and the thing that most affects this is the sheer number of files (equating to number of rows in the database) and how often/quickly you need them returned.
After all a filesystem is basically just a big database - albeit one highly optimised for the storage and retreval of files via a index structure rather than a generic relational database such as MySQL.
Storing files in MySQL is not technically difficult and there are a whole load of resources and tutorials showing you how to do it. You will of course have to handle the encoding/decoding, storing/finding and presentation (MIME types etc) yourself in code but again no big problem.
If your tables are indexed correctly, optimised and of a reasonable size then the seeking of files should be fairly quick.
But remember - doing an index search, loading the data into an array, processing (decoding or adding MIME headers) and then outputting will always be slower and much more process intensive than allowing the user to directly request the file from the filesystem via HTTP or just opening it yourself via PHP and streaming it out.
Have you maybe considered that? If your two servers can "see" each other then designate one the storage system. When files are uploaded get PHP to save them locally (on the designated storage server) or just in turn upload them to the storage server from the non-storage. When requesting a file the storage server just fopen()'s a file on it's local filesystem and the non-storage server does an fopen('http://my.storage.server/files/filename.whatever') instead.
Anyway - those are my confused and rambling thoughts on the matter.
Good luck with whichever implementation you go for.
Regards,
Dave.
Re: saving images into file or database
One thing I just thought about, was how much longer a backup will take