T.R | Title | User | Personal Name | Date | Lines |
---|
331.1 | Only when they do not speak | SNOC01::ANDERSONK | The Unbearable Lightness of Being | Wed Apr 12 1989 09:15 | 4 |
| No, it is not true (unless they meant that one of the nodes was
a non-VMS node :-(), and what is more, I think Rdb uses task to
task communication to talk node to node whereas I'd heard (could
be wrong) that ORACLE uses file transfers.
|
331.2 | Oracle in truth-telling shock | BISTRO::WATSON | different thoughts are good for me | Wed Apr 12 1989 12:16 | 13 |
| Oracle has told my customer that Rdb cannot join two tables on two
different databases located on different nodes in a network
It is, strictly speaking, true. You cannot, in a single FOR loop, cross two
tables unless they are in the same database (and hence on the same node). But
you can, in the same program, attach to both databases and use nested FORs to
use data from both databases.
So, if they are trying to imply that you can only talk to one database at a
time, or only to databases on your node, then they are misleading your customer.
Andrew.
|
331.3 | Not Cheap or Fast | SELL::BOOTH | What am I?...An Oracle? | Wed Apr 12 1989 16:35 | 22 |
| You are probably seeing the difference between a "coded cross" (the Rdb
method) vs. a transparent (from the user point of view) interactive
join. However, what Oracle fails to point out, is that to accomplish
this type of join with Oracle, the customer must buy SQL*Net ($25,000
on a 6240) and the DECnet Protocol software ($18,750 on a 6240).
In addition, the "transparent interactive join" works like this:
The user requests the data.
A process then queries the central dictionary to find the location(s)
of the requested data.
A set of file transfer commands are then issued to the locations
involved.
The data is then transferred to the user screen.
Needless to say, this is a slow process that tends to consume large
amounts of communication overhead.
---- Michael Booth
|
331.4 | Does the customer need this ?? | MAIL::DUNCANG | Gerry Duncan @KCO | Mon Apr 17 1989 04:45 | 18 |
| A few thoughts:
1. Does your customer NEED this functionality or is this a sales
"plant" by Oracle ??
2. Oracle doesn't have a network query optimizer (and neither do
we) so be sure the customer remembers that Ethernet can never perform
better than a native disk device.
3. Ask the customer if VAXcluster support is important for growth
and then pin Oracle down on their VAXcluster support since it is
a form of their shared database methodological. Since they can't get
VAXcluster to run right, what makes the customer think they can
do network traffic with any kind of performance either ?
If you need other ammo against Oracle, please call me at 452-3445.
Gerry Duncan @KCO
|