Using a plugin architecture allows sys admins to say, sacrifice
"performance" for better compression if they bare that need.

It also allows for better and/or more efficient compression methods to
be used as they come available. Certainly what we know as "good" now
wont forever be the case.

I also think a blunder comes along when you address the compression to
be done on the client side... if the compression mechanism changes
between versions for whatever reason, you will lose backward compatibility.

Maybe a better idea would be to have transmission compression and
storage compression. The transmission compression can be negotiated on
connection (useful for the poor client on a 486, where compression could
hurt more then help), and storage compression be whatever the server
feels appropriate.

Just some things to chew on.

Jason

Jim Starkey wrote:

> Si Carter wrote:
>
>
>>
>>
>>
>>Why not let the SYSDBA decide which compression algorithm to use via
>>plugins?
>>
>>
>>
>
> Why? Does he know more about it that we do? We're the database
> designer and are presumed to be the experts. You can't really argue
> that different blob types would benefit from different compression
> schemes if the compression algorithm is specified per database rather
> than per blob. So why would one DBA pick one algorithm and another
> equally knowledgeable DBA pick a different one? Also, if we want to
> support client side compression/decompression, it increases the platform
> burden. I'm willing to require that a client have code translate
> between his local character and Unicode (which he has to have anyway),
> but requiring that compression algorithms between scattered around the
> network seems unreasonable. And, unlike other plug-in based
> functionality, the failure to locate the correct decompression algorithm
> renders the database unreadable.
>
> I am constitutionally opposed to requiring humans to tell software how
> to run well. The software should be smart enough to figure that out for
> itself. Things like security requirements do vary from site to site,
> and flexibility via plug-in is a good thing. A purely internal artifact
> like compression algorithm should be studied and appropriately decided
> with enough mechanism in place to support a future re-evaluation.
>