From: "Geo." 

"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