I know this question was asked in various ways here, but none of the answer is conclusive.
I have a system which among other things updates a website gallery.
I can both "upload" the file to the website (and save a copy at the system - needed) or just save it in the DB and save the space (and another upload). If I go with the files I would need to "notify" the webpage of every change (picture delete, add or change) instead of just making the change in the DB.
So:
If we are talking about a standard website with a picture gallery, is it best to save the pictures as pictures or in the DB?
If the webpage is very visited or very large, does it makes any difference?
Is the difference that significant? Or just go with the convenient way?
Although I presented my case I would like also to have a "more in general" answer, what is the "good" approach when talking about saving files.
Thanks in advance for clarifying it,
Michel.
Only put structured data in a DB. Images are files and should be kept on a files system. The performance of the DB will degrade more and more as the number of pictures / users grows. Instead create an image object which you can use to track the image location and meta data.
I have had the same problem with you in a previous project of mine.
I decided to go with only storing the path of the image in my database (which is just a string) and save the image in the file system, not in the DB.
This is the best practice in many ways.
It keeps your DB small, getting a large amount of rows is faster and DB back ups are significantly smaller.
Just put the images in a file and save the path in the DB so you can retrieve it later.
Related
Is it possible to store .doc/.txt or image files to stroe in database directly making attributes of type blob?I neewd a good working example for storing files inside database and also obviously retrieving them from database as original.
The blog entry http://mirificampress.com/permalink/saving_a_file_into_mysql describes the overall process in quite allot of detail for php.
I have a huge MS Word file I use for personal notes but I want it to be more flexible. The file is made from short articles (600 words) with date, title, sometimes a table or some images. I came up with the idea of separating the single articles an put them in Access, to extract them from the database with queries, add tags, sort chronologically.
One big question is: which format should I use? I tried Access 2010 Rich Text Edit but it doesn't show tables, and I don't know where to store images. My idea is to store images outside the file.
Another thing I tried is to store the files as HTML in the database directory, but when I try to add some interface functionality I encounter problems with the most trivial things, like making VBA open the associated file. I don't like storing outside Access also because I don't have full-text search.
The primary requisite for this application is that it must not be cumbersome: it's a prototype I want to use to see if my model of storing notes works, so I don't want to spend a month programming an user interface, and if I note any defect at runtime I must be able to switch to design mode and fix it in minutes. If I want to write something, i don't have to worry about HTML syntax but I want to be able to add some simple table or image.
What I finally search is a HTML viewer in Access interface that receives an HTML string (composed by a query) and displays it.
At this moment I'm considering to remain with my MS Word file because switching seems too complex, although I don't like the sequentiality of articles and the hierarchy of chapters/subchapters, which made me think about this Idea.
The answer to all those problems was Evernote, which is like a Wiki you can edit quickly also from a smartphone, with or without an internet connection, which syncs to a master version on an Evernote server and without the constraint of having to invent a title for every page/idea.
If I had a huge Word document like yours, I'd probably split it into individual files and use something like dtSearch.
I have to display images on website and I can store image in the folder on my website and also I can store the image in image column of SQL Server.
So which way of storing image is better : in folder or in Image column of SQL Server.
1. Which way of storing image and retrieving it is faster
With SQL Server 2008, while you can store BLOB data, it's best to avoid it. I've done it in the past, grudgingly, and it did have negative performance implications. Unless you have some constraint which prevents it, use the file system. That's what it's built for, and it's much faster.
As #Martin Smith pointed out you could use FileStream. We started storing our files using FileStream so that we could also add full-text indexing and allow the users to not only search the data, but the files on our site. It is also nice because we can easily move our files along with teh Database to other environments (Dev, Test).
nice file stream Article: Here
Also, please use varbinary(max) if you are going to store in the DB. The image column is going to be deprecated in future versions.
--S
I am trying to prepare a sample question paper preparation app.
I am using tinyMCE editor and ajax-file-uploader plugin with it - as some questions may need images along with text.
How do I store my questions that have both image and text into MySql using PhP?
I would suggest storing the image on some sort of NAS or some other location, and store the path to the image in the database along with the other data in respective fields.
You can store the image in the DB but it is not good idea to retrieve and present the image from the database to the user (It doesn't perform that great either). There might be a performance hit
MySQL handles images very well. You insert them in BLOBs. On the other hand you could store the image file name and path or a link, as text in your DB.
Which solution is the best depends on the requirements of your application. In general if you have a huge amount of images, your database will become huge and backing up will be slow. There might be a similar impact on your file system in order to store a huge amount of images.
Here is the interesting Microsoft To BLOB or not to BLOB paper, that will give you more information on the topic and even some metrics.
I would echo the answers already given by #harigm and #Costis Aivalis but if you really wanted to go "all out" and store both the HTML content and the images in the same BLOB why not have a look at RFC 2557 which allows you to place binary data (like images) in the document itself using the url scheme data:. To make this work you will need to parse your HTML once it gets back to your server and base64 encode all the images to be placed in the HTML, quite a lot of work for what would probably turn out to be little reward.
I am wondering if this is possible and within the realms of Access?
I currently have a database system where the user can open up directories/folders related to the record; such as images, docs etc...
This avoids bloat by attaching the images to the records and what not, and works fine.
A user enhancement would be to allow the user to automatically compress photos so that they are more appropriate in file size to attach to emails.
I was wondering if it would be possible to, say whilst using the FileSystemObject and CopyFile, copy the photos from one folder (/photos) to another folder (/compressed_photos) and compress them at the same time.
Could I use "VBA.Shell" and run a batch image compression program on the photos?
Any advice on the above is greatly appreciated, even if it is just to confirm that it is not possible.
Cheers
Noel
A simple solution would be to use ImageMagick via Command Line. See the examples on the manual pages there.