Re: Foreign key in Oracle Sql
From: DA Morgan <damorgan_at_x.washington.edu>
Date: Sat, 15 Jan 2005 16:54:45 -0800
Message-ID: <41e9bb4e$1_1_at_127.0.0.1>
>
>
>
>
> There's a "relational problem" in not having an optimizer...
>
> That problem is that it means that implementation of the query
> processor becomes necessarily visible to applications.
>
> In order to use a system in a fashion that _isn't_ "real slow," you
> have to embed a more or less full understanding of how queries are
> processed into the application itself.
>
> A common feature of applications written for MySQL(tm) is that, over
> time, they become more and more attuned to its behaviour. If the
> application is pointed to another database product, it's obviously not
> specifically coded to that product's strengths, which tends to mean
> sucky performance.
>
> With Oracle(tm), it tends to be similar, where there are numerous
> temptations to use dramatically non-portable mechanisms to improve
> performance.
>
> Either way, this violates the principle of "Physical Data
> Independence," where it should be possible to change the underlying
> architecture of access methods or hardware without affecting how the
> application accesses it.
Date: Sat, 15 Jan 2005 16:54:45 -0800
Message-ID: <41e9bb4e$1_1_at_127.0.0.1>
Christopher Browne wrote:
> Clinging to sanity, "David Cressey" <david.cressey_at_earthlink.net> mumbled into her beard:
>
>>"-CELKO-" <jcelko212_at_earthlink.net> wrote in message >> >>>Do you have operations that expose a physical ordering in the >>>storage, such as the row number? Can you do subqueries? Is there >>>an optimizer? >> >>Operations that expose a physical ordering: bad idea, agreed. But >>you don't have to use them, do you?
>
>
>>Subqueries: I take it you mean incomplete support for SQL. If so, >>agreed. No Optimizer: As you know, if you know me, I really, really >>like a good optimizer. So, in terms of "goodness" I rate the >>quality of the optimizer very highly. But an optimizer is a "good >>feature", not a "relational feature". A real engine minus the >>optimizier is still a real engine. Just real slow.
>
>
> There's a "relational problem" in not having an optimizer...
>
> That problem is that it means that implementation of the query
> processor becomes necessarily visible to applications.
>
> In order to use a system in a fashion that _isn't_ "real slow," you
> have to embed a more or less full understanding of how queries are
> processed into the application itself.
>
> A common feature of applications written for MySQL(tm) is that, over
> time, they become more and more attuned to its behaviour. If the
> application is pointed to another database product, it's obviously not
> specifically coded to that product's strengths, which tends to mean
> sucky performance.
>
> With Oracle(tm), it tends to be similar, where there are numerous
> temptations to use dramatically non-portable mechanisms to improve
> performance.
>
> Either way, this violates the principle of "Physical Data
> Independence," where it should be possible to change the underlying
> architecture of access methods or hardware without affecting how the
> application accesses it.
I agree. But if the question is put to the marketplace ... which is more important ... portability or scalability and performance. Those that vote in dollars are not voting for portability.
The day they do ... the vendors will start caring about it.
-- Daniel A. Morgan University of Washington damorgan_at_x.washington.edu (replace 'x' with 'u' to respond) ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Received on Sun Jan 16 2005 - 01:54:45 CET