On Tuesday 29 April 2003 06:54 am, Ron Johnson wrote:
> On Tue, 2003-04-29 at 06:11, Andrew S. Johnson wrote:
> > On Tuesday 29 April 2003 12:52 am, Ron Johnson wrote:
> > > On Mon, 2003-04-28 at 18:39, Andrew S. Johnson wrote:
> > > > On Sunday 27 April 2003 08:53 pm, Dustin Puryear wrote:
> > > > > > > Is Oracle really as DBA-intensive as I've heard?
> [snip]
> > Set up the way I want them includes tuning. Applications I write get
> > tuned at the database design and PL/SQL level, which is why they
> > fly. Vendors who suck at database design and port apps from Access
>
> But databases are dynamic, even if no new applications come on-
> line, and interactive queries are disallowed.
Not always. Would a database on CD be dynamic? A database
that grows in size isn't necessarily dynamic, if the growth is linear
and expected. My definition of a dynamic database is one involved
in heavy development, or one where the DBA doesn't know enough
about the application and data to adequately tune it in advance.
Just because you can spend all day tweaking parameters doesn't
mean that the marginal return you might think you're getting is value
added for your employer. At some point you have to declare it good
enough and move on to something else, unless you have nothing else
to do.
> [snip]
> > SQL server is deeply tied to Windows, and I'm sure that Micros~1
> > says that it's helpful, but SQL server runs only on Windows. Oracle
> > runs well on dozens of platforms. Apache also runs on many platforms,
> > including Windows. I don't see tying the application to the OS as
> > an advantage, but rather a disadvantage in that updates to the OS
> > break applications. Sound familiar?
>
> No, at least with Rdb & VMS. Apps built against VAX Rdb 3.0 (from the
> late 1980s) will still run on VAXes running v7.3 and Rdb 7.1.
I'm sure that there are apps for which this is true. Are you saying that this
is the case for every app? Even if you did, I wouldn't believe it.
> Then again, the Rdb engineers work a short walk through the woods from
> the VMS engineers, and they understand the needs of enterprises. And
> can as the VMS engineers to implement special features, and can modify
> Rdb to take advantage of new features of Rdb.
>
> "Backward compatible, but forward looking."
>
> The benefits of the RDBMS knowing about the OS is that it's more
> efficient than a portable RDBMS that needs to maintain optimisations
> for every platform it runs on.
>
> Note, though, that just because "tying" is good, doesn't mean that
> MSFT does a good job at it...
DEC's tying RDB to VMS to VAX is what did them all in. Proprietary lock-in
has been on the way out for a while. People resent not having choices,
whether it's their vendor or their government. This is why tying is bad.
It's self-destructive behavior for a company.
Andy Johnson
___________________
Nolug mailing list
nolug@nolug.org
Received on 04/29/03
This archive was generated by hypermail 2.2.0 : 12/19/08 EST