IMO there are times when it makes sense to store binary content in a database,
and times when it does not.
My rule of thumb is based on size and usage. If you expect the amount of binary
content to grow tremendously, I would avoid storing binary content in the db.
Otherwise, for small items
On Mon, Mar 24, 2008 at 10:17 AM, Dave Ross [EMAIL PROTECTED] wrote:
IMO there are times when it makes sense to store binary content in a
database, and times when it does not.
My rule of thumb is based on size and usage. If you expect the amount of
binary content to grow tremendously, I
Lets say you get to be the size of myspace.com or flickr.com they
cannot be storing all of those images in a database would they?
It is very possible...
TerraServer:
http://terraserver-usa.com/about.aspx?n=AboutTerraServiceOverview
http://research.microsoft.com/displayArticle.aspx?id=272
The
Exactly - people who work in GIS will tell you a lot (if you ask)
about the power of DB systems that can do spatial analysis (Oracle,
for example).
On Mon, Mar 24, 2008 at 10:53 PM, Dawson, Michael [EMAIL PROTECTED] wrote:
Lets say you get to be the size of myspace.com or flickr.com they
Richard Dillman wrote:
I'm in the process of designing a site that will allow people to upload
(JPG,PDF,DOC,XLS) files. I'm looking at about 1-4 mb each item. Is it better
to do a file upload, or better to insert to the database?
I find keeping the images in the database is more manageable
I think the main thing in the end is the scope of the project and personal
preference.
If the site will maintain heavy load, especially the images section, then you
may want to consider a file server for uploads and just store the filename with
your record. This can take the strain off a
OMG! I could tell you some stories about government contracting.
I actually had an IOT manager in an SSL and Site security meeting ask just
how many extra guards he was gonna have to hire!!
.. . .
o.0
.. . .
Only 1 and, he wont have to be armed...
On Mon, Mar 24, 2008 at 2:33 PM, Dana
put the table holding the images on it's own file group
back that up separately from the main db. you do not have to back up the
images
along w/the rest of the data.
This is true until some one adds a new image to the database, then the
whole table
with all the images will have to be backed
But, you didn't take into account the amount of time it will take
to backup the file system.
What's important is that images are generally not modified, only added
or deleted,
so only new files will have to copied into the backup.
Is the images are in a table, the whole table will have to
Some databases can automatically extract metadata
(EXIF, for example).
Now this is completely ridiculous: if you really need things like what's
in EXIF, you extract it first
and store it in an appropriate record about the file, just as well as
width or height etc.
This does not justify storing
In my opinion, a database is used to organize related data. In this
case, a binary file would be related to its metadata that you would
normally store in a database.
Michael, if you have a table to organize data related to employees, will
you store the employees in the employee table?
--
Unless there exists some backup system that will only copy
new records?
Why, as a matter of fact, there is. It's called a differential database
backup.
http://msdn2.microsoft.com/en-us/library/ms181092.aspx
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Training:
Now this is completely ridiculous: if you really need things
like what's in EXIF, you extract it first and store it in an
appropriate record about the file, just as well as width or
height etc.
This does not justify storing all pixels and colors as well
in the database.
Perhaps this
Yes.
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 10:23 AM
To: CF-Talk
Subject: Re: Images in the database good or bad?
In my opinion, a database is used to organize related data. In
this case, a binary file would be related
I'm in the process of designing a site that will allow people to upload
(JPG,PDF,DOC,XLS) files. I'm looking at about 1-4 mb each item. Is it better
to do a file upload, or better to insert to the database? Honestly I'm
looking at a long-term answer here for a government contract. The items can
be
database, your database options are better when you don't do the
storing in the database.
William
::-Original Message-
::From: Richard Dillman [mailto:[EMAIL PROTECTED]
::Sent: Saturday, March 22, 2008 11:40 AM
::To: CF-Talk
::Subject: Images in the database good or bad?
::
::I'm in the process
Is it better to do a file upload, or better to insert to the database?
The basic idea of a database is to organize data in such a way it can be
searched and sorted.
In principle, there is nothing to be searched or sorted in an image, so
put it in the database
will just add an overhead on the
, I really like having the binary information stored with the
textual information.
m!ke
-Original Message-
From: Richard Dillman [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 22, 2008 1:40 PM
To: CF-Talk
Subject: Images in the database good or bad?
I'm in the process of designing a site
-Talk
Subject: Re: Images in the database good or bad?
Is it better to do a file upload, or better to insert to the
database?
The basic idea of a database is to organize data in such a way it can be
searched and sorted.
In principle, there is nothing to be searched or sorted in an image, so
put
William Seiter wrote:
Database backups and restores will happen MUCH faster and take up less
space.
that's an old myth. put the image bits on their own file group (sql server)
back them up once if they're static. in any case, if the images gotta be
backed up they gotta be backed up no matter
In my opinion, a database is used to organize related data.
Right.
In this case, a binary file would be related to its metadata
Right, the *file* is related, but nothing *inside the file* is, so you store
a reference to the file (ie; file name) in the database, but not what's
inside the
::Subject: Re: Images in the database good or bad?
::
::William Seiter wrote:
:: Database backups and restores will happen MUCH faster and take up less
:: space.
::
::that's an old myth. put the image bits on their own file group (sql
::server)
::back them up once if they're static. in any case
* Rollbacks of failed data transactions won't leave orphaned binary
files.
You have to store the file on disk anyway when it is uploaded.
If you also store the file content in the database, FIRST you have to
copy the file
from its temporary location to the database, which is an extra overhead
William Seiter wrote:
That is a current reality.
A database with 90,000 images in it will take longer to backup than a
database that doesn't have that binary data stored in it.
you missed the point, put the table holding the images on it's own file group
back that up separately from the
A database with 90,000 images in it will take longer to backup than a
database that doesn't have that binary data stored in it.
True. But, you didn't take into account the amount of time it will take
to backup the file system.
As Paul mentioned, you have to back up the images, somewhere,
Michael,
One of the things I have always been against is storing images into a database.
But you have raised a good point for smaller sites, that are not part
of a farm or cluster.
And the thing that I was going to say in this thread that no one else
seems to have touched on either is how heavy
It is considered best practice to use the file storage
facilities of the system hosting the application and only
store in the database information about the image, like file
name, size, type etc.
This is incorrect. You may consider it a best practice yourself, but there
is no longer a
I'm in the process of designing a site that will allow people
to upload
(JPG,PDF,DOC,XLS) files. I'm looking at about 1-4 mb each
item. Is it better to do a file upload, or better to insert
to the database? Honestly I'm looking at a long-term answer
here for a government contract. The
28 matches
Mail list logo
