On Fri, 01 Jul 2005 20:33:34 +0300, Miroslav Penchev wrote:

>On Fri, 01 Jul 2005 08:14:24 +0300, Fabricio Araujo
><fabricioa@...> wrote:
>
>>
>> Indexing on FB is much simpler: no need to worry to decide where
>> to put the clustering index. In MSSQL it is a key decision, on FB
>> is non-sense.
>>
>
>And you must do very often Update statistics for all tables to work
>optimizer at all. On relatively static system (max 100 operations on day)
>we must run sp_updatestats at least one time in a day. Of course that can
>be done with jobs but that I call "non-zero administration" ;) .

Very true.

>
>As someone mention - the logs are big problem to us. They grow very
>quickly and we must truncate them very often.

Hmmm... These ones don't bore me much, as my system is a simulation
one and using multiple databases, so these creatures don't get much
great...

>Backups also are not so smoothly. If you do every night backups - they
>must be differential. But if someone make a full backup somewhere else
>(for some reason), the job which do night backups is no more usable
>because you must make a full backup in the same device. That is also task
>for some DB Admin. That was hard to me to explain :)

What? That I didn't experimented myself... If you could explain better
(on private mail, of course)

>
>Also maintaining of database schema is risky - if some developer (or db
>designer) make some modifications of some view - all descendant views can
>stop working (in better case) or they in most cases will just return wrong
>results without any message and it is easily to miss that mess and place
>it in production. Also you can drop some DB object which is in use from
>some other object without any warning and of course these other objects
>will stop working (but you will notice that when you use them).

The problem here is that MSSQL give you the "ability" (read: rope to
hang yourself) to enter objects definition in any order you want *BUT*
not
mantaining the tree of dependencies (which, in consequence, has
"holes").
So, when you create n stored procedures dependents of each other, if
you drop an inner procedure and those are on one that "holes" on the
dependency tree, sorry you'll only discover when you run the outer
proc...
What a "marvelous" feature, huh?