As always, there are a number of concepts and ideas that should go into decisions that are made regarding storage systems.
One area for you to think about is location on the 'net of your image server, whatever form that takes. Since images take quite a bit of bandwidth to serve up, many times it is cost effective to have your own image server (or virtual server) located at a hosting company, while the dynamic "stuff" comes across on your own circuit. This very issue swayed me toward the image server concept, and not a database (altho for the right $$ I guess you could do the DB thing at a ISP). All of my code references an image server (eg; imgsrv1.domain.com) which can be CNAMED to be the same as your normal webserver for initial use then changed later as traffic builds. Just my $0.002 (inflation adjusted) ... Steve At 01:10 AM 12/7/2001 -0500, Steve Dworman wrote: >store them in the database... > >I was on a project recently where I suggested that the company store their >images on an image server. That was shot down because the Oracle DBAs said >that the database can manage itself. Therefore, the company wouldn't have >to pay someone to manage another server. SQL 2000 is almost a mirror image >of Oracle 8 (at least from my experience) and can handle BLOB and CLOB >types. > >The best way to insert these images is to write a batch process so you can >run and just forget about it. To insert the images you can just do an >"insert into" like you would with any other datatype. Your database will >not get bogged down if it's managed properly. I'm guessing the traffic >projections will require a solution such as multiple servers so you guys can >load balance. > >Again, 800,000 images will be better handled by the database itself rather >than a server admin managing an image server. I'll ask some of our DBAs for >concrete reasons tomorrow and get back to you. > >----- Original Message ----- >From: "Kelly Matthews" <[EMAIL PROTECTED]> >To: "SQL" <[EMAIL PROTECTED]> >Sent: Thursday, December 06, 2001 5:35 PM >Subject: Re: HELP with inserting a file into SQL > > >> Actually its a binary file was using image as an example. I think I am >going to suggest though, that we save the files themselves on a file server >with a unique name vs storing them in the database itself. That would >probably keep SQL from getting bogged down since there are going to be about >800,000 of these files over time and they will be between 1-2 megs in size. >:) We will be using SQL 2000. It's not a file that would ever need to be >retrieved via a website we are just going to be a STOREHOUSE for some FBI >fingerprint files... :) >> >> ---------- Original Message >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
