On Tue, 2003-04-29 at 17:37, Andrew S. Johnson wrote:
> 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
Well, no, because it is read-only.
> 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
That surely is one important definition of dynamic.
> about the application and data to adequately tune it in advance.
You can know everything about the app, and think you know about the
form the input data stream, but be mistaken. This is because not
all input data streams *can* be knowable. (Yes, guessable &
estimatable, but not knowable.)
For example: we do work for regional toll roads in the north east.
When we spec h/w during the contract bid process, the Agency must
give us their estimates about total traffic volume, growth, and
mixture between private and commercial customers, and cash vs. toll
tag customers.
Well, what if the Agencies' estimates are wrong? And they are
*always* really short, and always under-estimate the number of
customers who will use toll tags... In order for our bids to be
competitive, we must spec according to Agency estimates, knowing
that in a year we'll be coming back to them for a Change Order.
Then, the Agencies *always* start asking for new features soon after
the system goes live. (And they never stop asking, either.)
Lastly, all of these Agencies allow "cross-usage" of toll tags, so
every time another Agency joins the consortium, volumes change *again*.
Thus, if your databases are steady-state, and your apps don't change,
you are very, very fortunate.
> 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.
See above.
> > [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.
Certainly not for apps that were built against versions of Rdb after
3.0...
My point was that tying the DBMS to the OS *can* be done well,
beneficial for all.
> > 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.
That's the least of the reasons why DEC failed.
Remember, also, that DEC ported VMS to Alpha 11 years ago, and is
in the process of porting it to Itanium (it's already bootstrapped
in the lab, with FCS later this year).
-- +-----------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | An ad currently being run by the NEA (the US's biggest | | public school TEACHERS UNION) asks a teenager if he can | | find sodium and *chloride* in the periodic table of the | | elements. | | And they wonder why people think public schools suck... | +-----------------------------------------------------------+ ___________________ Nolug mailing list nolug@nolug.orgReceived on 04/29/03
This archive was generated by hypermail 2.2.0 : 12/19/08 EST