Storing images
Slav Inger
I have the need to store images of simulation models into SQL Server 7.0
while using ASP to do this. The images could be pretty large. I'm
thinking of using the HTML form input type "upload" to pull files from
the user. But I'm not sure how to go about storing the images within
the SQL Server tables or on the filesystem. Is there a practical
example/tutorial somewhere on the Net?
Thanks.
- Slav Inger.
- vin...@mail.ford.com
Carl Appellof
Slav Inger <vin...@mail.ford.com> wrote in message
news:38274BBA...@mail.ford.com...
There are lots of great examples of storing image data in SQL server Books
Online. The new "image" datatype is ideal for storing very large blobs of
data.
Carl Appellof
Legato Systems Inc.
Daniel Andrews
file path in a DB. Pulling Images from a DB is slow compared to the File
System. Using Directory Naming Convetions makes this an easier task than a
DB Anyway, besides it is easier to maintain this way.
Daniel Andrews - Developer
Click Interactive, Inc.
and...@clickinteractive.com
>Hello,
>
>I have the need to store images of simulation models into SQL Server 7.0
>while using ASP to do this. The images could be pretty large. I'm
>thinking of using the HTML form input type "upload" to pull files from
>the user. But I'm not sure how to go about storing the images within
>the SQL Server tables or on the filesystem. Is there a practical
>example/tutorial somewhere on the Net?
>
Stephen Johnson
quite nicely from a database. I stored all images for my website in a SQL 7
database (approx. 2000 currently) and you will find it to be just as fast or
faster than the file system. Additionally backup and restore of the database
also takes care of your images and cleaning up the images is just deleting a
record. Go to www.weezgot.com if you want to take a look. FYI, images are
stored in the database via web browsers. I have written an ISAPI.dll which
does this and not an ASP so if anyone wants help doing this via ISAPI dll
email me directly.
Sincerely,
Stephen Johnson
Daniel Andrews <and...@clickplanet.com> wrote in message
news:808o5t$rmn$1...@eve.enteract.com...
Daniel Andrews
Nothing is faster than the system i/o of which the file system is an overlay
(Leave IMDB's out of this). So I find it unlikely that the file system
will be slower than database access. Simple fact is the DB is a file
itself. putting it in a DB adds at least 1 more layer, probably 2 or 3
more.
However nice job with the site.
Copy *.* [Physical Disk]:[PATH] -Backup & Restore
Del [Filename] - Delete
Daniel Andrews
Daniel Andrews
Carl Appellof (GTE)
> Stephen,
>
> Nothing is faster than the system i/o of which the file system is an
overlay
> (Leave IMDB's out of this). So I find it unlikely that the file system
> will be slower than database access. Simple fact is the DB is a file
> itself. putting it in a DB adds at least 1 more layer, probably 2 or 3
> more.
>
But the filesystem has to do a lookup to find the file by name. So does the
database engine. Speed could be about the same. And the DB COULD be placed
on a raw device if you wanted to, avoiding the filesystem entirely.
Carl Appellof
Tibor Karaszi
difference algorithms between a file server and a DBMS in cache handling.
--
Tibor Karaszi
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Cornerstone Sweden AB
Please reply to the newsgroup only, not by email.
Carl Appellof (GTE) <res0...@gte.net> wrote in message
news:IHtW3.215$x24....@paloalto-snr1.gtei.net...
Daniel Andrews
>Daniel Andrews <and...@clickplanet.com> wrote in message
>news:80bch2$pqf$1...@eve.enteract.com...
>> Stephen,
>>
>> Nothing is faster than the system i/o of which the file system is an
>overlay
>> (Leave IMDB's out of this). So I find it unlikely that the file system
>> will be slower than database access. Simple fact is the DB is a file
>> itself. putting it in a DB adds at least 1 more layer, probably 2 or 3
>> more.
>>
>
>But the filesystem has to do a lookup to find the file by name. So does
the
>database engine. Speed could be about the same. And the DB COULD be
placed
>on a raw device if you wanted to, avoiding the filesystem entirely.
>
>Carl Appellof
>
>
>
Carl,
Speed won't even be close, the filesystem is not based on names, instead it
based something called sectors which contain byte streams. It ends up being
at least two more function calls (in,out) , and if you are getting a
thousand hits a pointer to a byte stream already in place is faster than the
one you have to contstruct from the DB data stream. In terms of
scalability, files for images do much better than any DB. Also remeber any
binary information stored in a DB is not compressed meaning it has faster
access than regular DB calls but require much more permanent storage. Which
leads me to the fact that I get no storage(size) benefit from storing images
in a DB, so go with speed (filesystem).
Not to Carl, but to the guy who keeps emailing me at work.
I will not advocate storing images in a db. In the Future if I were you I
would not consult with so clearly an unbending client. They hired you based
on your strengths and experience, if you have no experience storing images
in a DB, then point that fact out to them. Give them pros and cons, what
you prefer and why, If their IT guys disagree with back yourself up (Not
with the usual Newsgroup exchanges, but load tests, case studies, scientific
articles, and of course books by experts.) They hired you because you are a
professional at what you do, and you are damn sure better than anyone they
have or they wouldn't have hired you. I am sure someone in that company's
chain of command will agree that your check warrants the company to heed
your advice over IT Staff disagreements.