Re: Portable way to DROP a COLUMN?..

Mikhail Teterin wrote:
> "Jim Kennedy" <jim dot scuba dot kennedy at gee male dot com> wrote:
>
> > Dropping a column isn't trivial and should only be done when absolutely
> > necessary.
>
> Whether the task is trivial is besides the point.
>
> What certainly is (or ought to be) trivial is the syntax for the operation.

Yeahhh, but you know the syntax for
select * from table_a is the same for probably every database, but it doesn't mean you'll get the same results back. Look at the classic example Oracle vs MS SQL Server where in Oracle you'll get read consistent view in time but in SQL Server (at least without special precautions and I don't know what is in the very last version) you'll get dirty reads. So sometimes syntax doesn't even matter, the architecture and implementation may be different.

>
> > Think about what occurs when you drop a column. [...]
>
> DB-vendors collect thousands of dollars just so that I don't have to "think
> about what occurs" in the DB back-end, and can concentrate on my
> application. This was is the promise of the standalone database servers...

You know politicians also promise to do this and that but it by no means doesn't prevent them to do all things differently. DB vendors are implementing features (mostly? always? sometimes?) on their own and each feature can be implemented in many ways. You can of course don't worry how it is implemented and look only at the upper level but then most probably you'll get an application that won't perform at its best and probably even will perform worse than you expected. So whether this probability seems important enough to worry about it is your own decision.

>
> Dropping a column is a legitimate operation (required, for example, when the
> data-model changes during application's upgrade), and there is no excuse
> for there not being a standardized SQL way of doing it. Having such
> standardized vendor-agnostic way for all (most?) operations is another big
> promise...

As I've said each feature can be done in many ways and standard doesn't enforce how to do that, so in one DB feature A can be very advisable, but in other probably not. And speaking about promises - it is business, $$$ and to be ahead of competitors, who cares about promises? :)
That's hard life :)

Gints Plivna
http://www.gplivna.eu Received on Fri Sep 22 2006 - 00:15:36 CDT