From: Thees Peereboom 

Geo,

Again valid points. I agree with your implied statement that each case
should be judged on it's own merits. Growth can be a problem, but not only
with the db. It usually has many aspects, in this particular case
phonelines, people to attend the phones, etc. The db would only be one of
your problems .

BTW, aren't BLOB's stored as separate files by the DBMS?

- Thees Peereboom

On Sat, 28 Dec 2002 09:51:56 -0500, "Geo."  wrote:

>"Thees Peereboom"  wrote in message
>news:kj3r0vov1lcn4snlghva6ov57fvcg70jo1{at}4ax.com...
>
>> This is only part of the equation. To know whether things are rare or
>> common is one thing but to calculate your risk you should multiply
>> this with the severance. If chances are rare, but *when* it happens it
>> will destroy your company, you'd  better take precautions. If its rare
>> *and* the implications are limited, you'd better not bother and cross
>> that bridge when getting there.
>
>I agree but there is a third part to this formula, how hard is it to set
>things up to avoid the loss right from the beginning. If it's a simple
>configuration change that can be done and once it's done it doesn't get in
>anyone's way then why not protect yourself from everything possible, even
>rare things, right from the start?
>
>See my thinking on this is a little bit like saying why don't you take all
>your MP3 files and store them in one huge file instead of a bunch of
>separate mp3 files. I don't like that idea because one problem with that
>huge file and they are all lost whereas if stored as separate files it's
>much easier to recover from a bad sector or something like that.
>
>The SQL database stores everything in one huge file, fine for lots of little
>pieces of data but I don't like the idea of storing multimeg mp3 files that
>way because the database will be absolutely huge and the bigger it is the
>more likely it is to:
>
>1) have a problem because of the disk surface
>
>2) take forever to restore from tape should you need to bring it back for
>some reason
>
>3) do maintenance on it
>
>4) load balance
>
>5) keep it on a single partition as it grows
>
>You have a music management program to manage your MP3 files? Does it store
>pointers or does it include all the MP3's in one large database?
>
>See, if we were talking about 5K jpg files I might view that differently but
>a phonecall can easily take a meg or more of disk, even in compressed
>format. I understand why Ellen want's them in the db, it makes her job a lot
>easier writing software to access the files but from my pov being the guy
>who has to manage system growth, run backups, run restores, and generally
>keep things going I have other concerns, what makes ellen's job a little
>more difficult writing the program once makes my life much easier for the 10
>year lifetime of the system. It's a pov that is not always considered when
>designing these db systems.
>
>Ellen has already seen what happens when you run out of disk space, how big
>is this raid array, 100g? What happens if they suddenly experience a growth
>spurt and they need to store 3tb of calls? You going to redesign the system
>right when it's needed most? (growth is a great problem to have and one I've
>seen many times)
>
>Maybe I just look at these things differently because I've always been the
>guy who got stuck with 5 year old systems and a new set of requirements that
>were never considered during the initial design phase. Because of that I
>always look to keep my options as open as possible, I don't like to commit
>to a limitation unless there is clearly something very valuable gained by
>accepting that limitation. Seems to me there is a lot of value in using sql
>server to do the lookup functions and then serve the actual recordings from
>a file share or even set of recording servers that could be located
>anywhere, even locally in each department to reduce network traffic as the
>system grows. If you had to move a section of the recordings you could copy
>them to a new machine then just run a query to modify the pointers with
>almost no downtime at all, it would be very flexible in this regard. It's
>that kind of flexibility that comes in real handy several years later when
>the water level starts to rise and your admin is sitting there saying "what
>do you mean I can't "..
>
>Geo.
>

--- BBBS/NT v4.01 Flag-4