No flame wars, please!
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
Thanks.
Mike
43  4710 
Mike wrote: No flame wars, please!
We're planning a move from a non-relational system to a relational
system. Our choices have been narrowed to Oracle and DB2. Since we're
moving from non-relational to relational, then we're not currently
using any relational-type operators. So I expect the end result to use
simple, SQL standard commands and queries.
The question: At the SQL standard level is there any appreciable
difference between Oracle and DB2.
I never used Oracle since I could not understand the requirements of their
contracts, and refuse to agree with things I do not understand. It also
seemed that they cost too much for the dual processor machine I proposed
to run it on.
Example: I know that Oracle has cascading deletes. We're not using them
now so I don't expect to use them with the new system.
DB2 can do cascading deletes in several ways.
If you are presently running flat files, a hierarchical dbms (such as
IBM's IMS/DB), or a network model dbms, you may find that the ways of
doing things relationally are so different from what you are used to that
assuming you will, or will not, use certain features ahead of time will
almost certainly be premature.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 12:10:01 up 21 days, 3:47, 3 users, load average: 4.18, 4.14, 4.10
"Mike" <mi***@mikee.ath.cx> wrote in message
news:10*************@corp.supernews.com... No flame wars, please!
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
Thanks.
Mike
Since I am responding from an Oracle news group Oracle would be the best
choice.
I will say this porting to a new system should be a rewrite not a port.
The architectures between a non-relational and a relational system are very
different. You need to cover a lot of ground before your system is going to
work well.
Jim
Don't forget that when establishing a new environment you will need
servicable copies of the database product for:
1. Production
2. Quality Assurance
3. Development
4. Emergency recovery
Your business needs will control how many copies of the product you'll
need licenses for. Be sure to examine the costs of going to a larger
production system, both in a single box (ie. multiprocessor or faster
processr) and the potential for a distributed system requiring multiple
database engine boxes.
UDB comes in many flavors, each having a different target use and
associated cost.
Phil Sherman
Mike wrote: No flame wars, please!
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
Thanks.
Mike
OK ... so you cross-post to comp.databases.ibm-db2 and
comp.databases.oracle with a subject line of "db2 vs. Oracle", and then
you request no flame wars? I won't hold my breath!
At the SQL level (as you put it), DB2 employs ANSI SQL ... and is the
only RDMBS vendor to employ a stored procedure language that complies
with ANSI's PSM standard.
Larry
Mike wrote: No flame wars, please!
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
Thanks.
Mike
Mike <mi***@mikee.ath.cx> wrote in message news:<10*************@corp.supernews.com>... The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
The simple answer is no: each have their own strengths & weaknesses,
but these tend to be nuances and each are otherwise very ansi sql
compliant.
The complex answer is it depends: on exactly what you want to do with
this database. I've had to make quite a few purchasing
recommendations in the past, and to be honest, sql features has never
been a deciding factor (between major commercial products). Licensing
costs, vendor strategy, vendor/product viability, solution
managability, skills availability, third-party support, performance &
scalability - these were the factors that typically influenced the
decision the most.
DB2 & Oracle are very competitive in my opinion. Oracle has more
mindshare, third-party support, and features than DB2 does. DB2 is
slightly more primitive, but also simpler and cheaper. DB2 also has
some very high-end scalability capabilities if you're in the data
warehousing world.
Coming from flat files, vsam, ims/db, or mysql these db2 & oracle
probably look about the same. But once you get much closer and start
working with them the differences loom large. ;-)
Buck Nuggets wrote: Mike <mi***@mikee.ath.cx> wrote in message news:<10*************@corp.supernews.com>...
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
The simple answer is no: each have their own strengths & weaknesses,
but these tend to be nuances and each are otherwise very ansi sql
compliant.
The complex answer is it depends: on exactly what you want to do with
this database. I've had to make quite a few purchasing
recommendations in the past, and to be honest, sql features has never
been a deciding factor (between major commercial products). Licensing
costs, vendor strategy, vendor/product viability, solution
managability, skills availability, third-party support, performance &
scalability - these were the factors that typically influenced the
decision the most.
DB2 & Oracle are very competitive in my opinion. Oracle has more
mindshare, third-party support, and features than DB2 does. DB2 is
slightly more primitive, but also simpler and cheaper. DB2 also has
some very high-end scalability capabilities if you're in the data
warehousing world.
Coming from flat files, vsam, ims/db, or mysql these db2 & oracle
probably look about the same. But once you get much closer and start
working with them the differences loom large. ;-)
I too am responding from the Oracle usenet group but my comments will
be as non-inflammatory as possible.
A. Based on what you posted either product could meet your needs as the
information you provided is nearly as substantial as a vacuum.
B. What internal skills do you and your team have? You indicate no
prior knowledge of SQL. Do you think you are going to pick up either
of these products without classes and books? Have you looked for local
classes? Have you looked at the book resources available? Have you
looked for local expert resources to support and mentor your team?
C. What operating systems are you and your team familiar with? Do you
expect to be running this on Windows? Linux? some flavour of UNIX?
mainframes?
D. What are your security requirements? Are you expecting to host a
web site?
E. What are your anticipated transaction volumes in terms of number of
transactions? Number of simultaneous transactions? Transaction sizes?
F. Does what you are building require a front-end? GUI? Web?
Client-Server? What tools? What connection mechanism?
I could list a good 20 to 30 more without even beginning to exhaust
the basic criteria that are the minimum set from which your decision
should be made.
Absent these answers anything you get in a usenet group will be worth
what you paid for it.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
which choices did you look at ?
did you consider Ingres ?
Mike <mi***@mikee.ath.cx> wrote in message news:<10*************@corp.supernews.com>... No flame wars, please!
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
Thanks.
Mike
at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.
on
the other hand, 390 db2 is just as needy. oracle is said to be a dog
on
the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.
there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.
your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.
hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.
Comments in-line. at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.
Perhaps in the past. Certainly not with 10g.
on the other hand, 390 db2 is just as needy. oracle is said to be a dog
on the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.
there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.
your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.
hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.
I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Daniel Morgan <da******@x.washington.edu> wrote in message news:<1093580524.649947@yasure>... Comments in-line.
at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.
Perhaps in the past. Certainly not with 10g.
on the other hand, 390 db2 is just as needy. oracle is said to be a dog
on the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.
there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.
your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.
hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.
I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.
You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
> You're using a wrong approach to determine the RDBMS that will suit your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.
But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Flame wars .... here we come! <sigh>
Ollie wrote: You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
Oracle is as good, if not better, with OLTP as the others.
Like any environment, you have to understand it properly to be able to use
it properly.
Statements like "I don't think Oracle will bet UDB, Sybase or SQL Server
...." generally are based on "I learned how to do it efficiently on 'x' but
those principals don't apply to 'y' therefore 'y' is bad."
Of course, Ollie is using a traditional 'more competitor names is relevant'
tactic, conveniently forgetting that Sybase sold their soul to Microsoft by
giving them what is now SQL Server.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
Oracle Backup and Recovery is not difficult - you do need to understand it
though. Since backups are really only relevant for recovery, the course is
designed to give a large number of scenarios in recovery that you actually
practise so that you do not need to 'practise' or look like a dodo to
mamangement when a crash actually occurs.
Besides, the course includes other items, such as Oracle Networking.
My point is that Ollie is attempting to use irrelevant information, or pure
FUD, to prove his point.
Religion in software, like ignorance, is bliss.
/Hans
In article <82**************************@posting.google.com >, Ollie wrote: Daniel Morgan <da******@x.washington.edu> wrote in message news:<1093580524.649947@yasure>... Comments in-line.
> at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
>
> on the other hand: oracle and db2 use diametrically opposite
> concurrency
> mechanisms. oracle is said to require more husbanding than oracle.
Perhaps in the past. Certainly not with 10g.
> on the other hand, 390 db2 is just as needy. oracle is said to be a dog
> on the 390 (at least by blue folk). oracle is pretty much the same on
> any platform. db2 is pretty much different on any platform. oracle
> has
> most of the mindshare on *nix (except AIX, natch), and it's largest
> install segment. it doesn't exist (IIRC) on AS/400.
>
> there are studies which show Total Cost of Ownership to be higher with
> oracle. ditto db2.
>
> your biggest effort, should you choose to do so (most COBOL/VSAM folk
> don't), is defining a relational structure which balances the
> concurrency
> stuff you get free in a (R)DBMS with the existing code base, which
> was/will be doing it too. you'll need to decide. if you use the DB
> concurrency stuff, you should remove it from the code. if you leave
> it
> in the code, you'll get it from the DB anyway, and performance could
> be
> anywhere from a little worse to in the toilet. depends.
>
> hire a consultant. one that has documented experience with systems on
> your platform and oracle and db2 on that platform. it's your only
> hope.
I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.
You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
Thank you and everyone for your opinion. I have DBA'd and
developed for most databases out there (Oracle, Sybase,
Informix, Unify, Ingres, open source, etc.) except
for DB2. I know and understand their strengths and
weaknesses. I also very well understand my company's
current application and where they want to be in two years.
While most find my original question too general to answer,
and being general felt I was focusing on the wrong aspects
of my needs, I asked the question intentionally and have
received the responses I need.
Mike
Interesting viewpoints about Oracle vs IBM.
I recently scanned through the autobiography about Larry Ellison called
"SOFTWAR", at my local bookstore. Very interesting book, and full of a
lot of interesting information, and lots of innaccuracies. The telling
point at least to me was about Larry and what the company is all about.
( You can find it in the business book section under "arrogance" 8-)
In the book they mention that Oracle is more about applications than the
database. If you have an application that requires Oracle, you will indeed
have to use Oracle. But I would caution against using Oracle as a database
choice especially in light of where your people are in skills. In Larry's
own words they indicate the direction of the company has less to do with
being a database company and more to do with applications. Larry is in
his own words more interesting in winning than providing a product that
is indicative of being a good technology choice. Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.
IBM has an excellent set of databases, and the company can also sell you
a complete end-to-end solution, meaning hardware as well as software. I
have seen the latest results on benchmarks and both Oracle and DB2 are
at the top. IBM will dominate the landscape with Power5 hardware, and
Power6, etc. with loads of innovation that I do not see coming from
any other vendor.
It is indeed important to make the choice in the right context as others
have indicated. Should it really be Oracle vs DB2 as a database choice?
Or in your case DB2 vs SQL-Server or Ingres or MySQL or Informix? These
are database products that would probably be more suited to a comparison
today. Incidentally Oracle has not had a major architectural change in
its engine since V7, and that was what, 10+ yrs ago? SQL-Server hasn't
had a major upgrade in what 6 yrs? DB2 has been changing rapidly to meet
the market, and so are a few of the others. Go with the latest not the
late. Interesting too that DB2 is morphing very rapidly, responding to
what customers want. This should be a big checkbox no matter what your
choice. You won't need the grid unless you're part of the SETI project.
Daniel Morgan wrote: You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.
But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.
Data Goob wrote: In the book they mention that Oracle is more about applications than the
database.
And this is a surprise to you? Where have you been hiding?
Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.
Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering" in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
I remain jealous of you Daniel for having access to really good weed! It seems
to have the intended effect. Must be that stuff from Vancouver I heard about.
Anyway since you opened the door...
DB2 is far less difficult to understand and master than Oracle. More specifically
Oracle is the difficult database, whereas DB2 is a breeze to install and use.
Oracle is a collection of disparate pieces of bolt-on software that requires years
to "master" and lots of people to make it successful. This is why it is happy
in larger organizations and completely inappropriate in smaller ones. DB2
has a clearly defined scalability that Oracle has yet to implement. Instead
Oracle continues to opt for smoke and mirrors. 10g has yet to be proven in
the business world as even relevant, much less RAC ( bwaahahaaaa! :-) I would
say DB2 and SQL-Server are more equivalent in ease of use, but the differentiator
in DB2 is that it can scale way beyond what SQL-Server can, on low-cost hardware,
and O/S. Oracle requires a lot of money, time, and hardware, something I would
be very concerned about as a business wanting to be competitive and keep costs
down. Of course if money is no issue, go for Oracle, it will increase Larry's
wallet and decrease your own. Ford Motor by the way recently decided that using
Oracle was a good learning experience, but not suitable for their business after
what, 5 years of dicking around with it. ( See Eweek )
Daniel Morgan wrote: Data Goob wrote:
In the book they mention that Oracle is more about applications than the
database.
And this is a surprise to you? Where have you been hiding?
Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.
Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering" in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.
"Data Goob" <da******@hotmail.com> wrote in message
news:7x**************@fe10.usenetserver.com... I remain jealous of you Daniel for having access to really good weed! It
seems to have the intended effect. Must be that stuff from Vancouver I heard
about.
Anyway since you opened the door...
DB2 is far less difficult to understand and master than Oracle. More
specifically Oracle is the difficult database, whereas DB2 is a breeze to install and
use.
Oracle is a collection of disparate pieces of bolt-on software that
requires years to "master" and lots of people to make it successful. This is why it is
happy in larger organizations and completely inappropriate in smaller ones. DB2
has a clearly defined scalability that Oracle has yet to implement.
Instead Oracle continues to opt for smoke and mirrors. 10g has yet to be proven
in the business world as even relevant, much less RAC ( bwaahahaaaa! :-) I
would say DB2 and SQL-Server are more equivalent in ease of use, but the
differentiator in DB2 is that it can scale way beyond what SQL-Server can, on low-cost
hardware, and O/S. Oracle requires a lot of money, time, and hardware, something I
would be very concerned about as a business wanting to be competitive and keep
costs down. Of course if money is no issue, go for Oracle, it will increase
Larry's wallet and decrease your own. Ford Motor by the way recently decided
that using Oracle was a good learning experience, but not suitable for their business
after what, 5 years of dicking around with it. ( See Eweek )
You know not what you write about. I worked for a company that included
Oracle as the database for an Electronic Medical Records company who's main
customers were ambulatory care centers. (Your standard Dr.'s office) The
customer did not need nor did they have a DBA or even an IS department on
staff. Someone who was desktop savy could install the whole system from the
excellent step by step documentation. (we started on Oracle 7.1 which was
current at the time) People ran it for many years without a problem and as
long as they followed the procedures in our manual (eg backup, hot or cold)
then they didn't have any problems even if they had to restore. They
usually called us for restores. We were installed at several thousand sites
all across the US. Dr. offices are very cheap and they did not willingly
hire people just to administer the system. We supported Oracle running on a
variety of platforms. (Netware, NT, HPUX, and if we had a larger QA
department could have easily supported Sun and AIX. QA, understandably,
wanted to run complete regression passes for every platform. With about 150
employees in the entire company at the time, there were just not enough
resources to reasonably do it.)
So one can set things up incorrectly and cause all sorts of headaches and
make work, but if you take a little care and set it up right you don't have
to spend time screwing around.
So you are completely wrong. Oracle has gotten easier to administer since
7.1.
Jim
Daniel Morgan wrote:
Data Goob wrote:
In the book they mention that Oracle is more about applications than
the database.
And this is a surprise to you? Where have you been hiding?
Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really
even applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.
Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering" in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.
Jim,
Thanks for your comments. I disagree that I'm 'completely' wrong, but it
doesn't really matter, I'm not using Oracle. Oracle is a beast of a pig
all the way around, but you would only know that if you used something
besides Oracle. Oracle has excellent marketing, pay no attention to the
man behind the curtain.
Thanks!
Jim Kennedy wrote:
You know not what you write about. I worked for a company that included
Oracle as the database for an Electronic Medical Records company who's main
customers were ambulatory care centers. (Your standard Dr.'s office) The
customer did not need nor did they have a DBA or even an IS department on
staff. Someone who was desktop savy could install the whole system from the
excellent step by step documentation. (we started on Oracle 7.1 which was
current at the time) People ran it for many years without a problem and as
long as they followed the procedures in our manual (eg backup, hot or cold)
then they didn't have any problems even if they had to restore. They
usually called us for restores. We were installed at several thousand sites
all across the US. Dr. offices are very cheap and they did not willingly
hire people just to administer the system. We supported Oracle running on a
variety of platforms. (Netware, NT, HPUX, and if we had a larger QA
department could have easily supported Sun and AIX. QA, understandably,
wanted to run complete regression passes for every platform. With about 150
employees in the entire company at the time, there were just not enough
resources to reasonably do it.)
So one can set things up incorrectly and cause all sorts of headaches and
make work, but if you take a little care and set it up right you don't have
to spend time screwing around.
So you are completely wrong. Oracle has gotten easier to administer since
7.1.
Jim
So I guess years of using and having experience with Oracle, DB2, Ingres,
Sybase, Sql Server, XDB, SQL Base (Centura), Btrive, dBase (padadox,
CLipper, Foxpro),my SQL, Isam and others is just too narrow an experience.
I as far as I remember Goob is a pile of mess of buggers. At least my kids
say so.
Jim
"Data Goob" <da******@hotmail.com> wrote in message
news:Zs***********@fe55.usenetserver.com... Jim,
Thanks for your comments. I disagree that I'm 'completely' wrong, but it
doesn't really matter, I'm not using Oracle. Oracle is a beast of a pig
all the way around, but you would only know that if you used something
besides Oracle. Oracle has excellent marketing, pay no attention to the
man behind the curtain.
Thanks!
Jim Kennedy wrote:
You know not what you write about. I worked for a company that included
Oracle as the database for an Electronic Medical Records company who's
main customers were ambulatory care centers. (Your standard Dr.'s office)
The customer did not need nor did they have a DBA or even an IS department
on staff. Someone who was desktop savy could install the whole system from
the excellent step by step documentation. (we started on Oracle 7.1 which
was current at the time) People ran it for many years without a problem and
as long as they followed the procedures in our manual (eg backup, hot or
cold) then they didn't have any problems even if they had to restore. They
usually called us for restores. We were installed at several thousand
sites all across the US. Dr. offices are very cheap and they did not
willingly hire people just to administer the system. We supported Oracle running
on a variety of platforms. (Netware, NT, HPUX, and if we had a larger QA
department could have easily supported Sun and AIX. QA, understandably,
wanted to run complete regression passes for every platform. With about
150 employees in the entire company at the time, there were just not enough
resources to reasonably do it.)
So one can set things up incorrectly and cause all sorts of headaches
and make work, but if you take a little care and set it up right you don't
have to spend time screwing around.
So you are completely wrong. Oracle has gotten easier to administer
since 7.1.
Jim
Data Goob wrote: Interesting viewpoints about Oracle vs IBM.
I recently scanned through the autobiography about Larry Ellison called
"SOFTWAR", at my local bookstore. Very interesting book, and full of a
lot of interesting information, and lots of innaccuracies. The telling
point at least to me was about Larry and what the company is all about.
( You can find it in the business book section under "arrogance" 8-)
So your comments are based on a brief scan of a 500 page book in a
bookstore, written by a journalist about a single person, and on that
you determine the usefulness of the technology produced by over 40,000
other people ? Great analysis.
http://www.urbandictionary.com/define.php?term=goob&r=f
In the book they mention that Oracle is more about applications than the
database. If you have an application that requires Oracle, you will indeed
have to use Oracle. But I would caution against using Oracle as a database
choice especially in light of where your people are in skills. In Larry's
own words they indicate the direction of the company has less to do with
being a database company and more to do with applications.
Complete and utter bullshit. You have absolutely NO basis for your
characterization, yet you make it. Why ?
Larry is in
his own words more interesting in winning than providing a product that
is indicative of being a good technology choice. Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements.
You obviously have no idea how the grid applies to business. Note that
one of the foremost proponents of the grid architecture is indeed Ford.
Oracle will be a big nut
to crack in an organization that has never used a relational database.
2 days is all it takes - see
http://download-west.oracle.com/docs...b10742/toc.htm
Scan it online.
IBM has an excellent set of databases, and the company can also sell you
a complete end-to-end solution, meaning hardware as well as software.
They cannot actually sell you any business applications, can they. A
complete end-to-end as long as you take the actual business out of the
definition of the solution (you know, HR, General Ledger, Mnaufacturing,
Supply Chain etc). You are a silly person.
I
have seen the latest results on benchmarks and both Oracle and DB2 are
at the top. IBM will dominate the landscape with Power5 hardware, and
Power6, etc. with loads of innovation that I do not see coming from
any other vendor.
Correct - IBM hardware is very,very good. Both Oracle and DB2 run very
well on it.
However, hardware innovation does not = software innovation.
DB2 is NOT particulary innovative software, and indeed, a large part of
the DB2 software devleopment plans are to provide features from other
databases to aid in migration from SQL Server and Oracle - witness the
addition of both indentities and sequences in the last couple of
releases. The latest release of DB2 is a prime example of this - there
is very little that is actually innovative (or even new) in the 8.2
release.
It is indeed important to make the choice in the right context as others
have indicated. Should it really be Oracle vs DB2 as a database choice?
Or in your case DB2 vs SQL-Server or Ingres or MySQL or Informix? These
are database products that would probably be more suited to a comparison
today. Incidentally Oracle has not had a major architectural change in
its engine since V7, and that was what, 10+ yrs ago? SQL-Server hasn't
had a major upgrade in what 6 yrs? DB2 has been changing rapidly to meet
the market, and so are a few of the others.
You are confusing two things. All databases meet new market
requirements, some faster than others, and none of them should require
major architectural changes to do so. If a database company has required
a major architectural change in the last 10 years to meet new market
requirements then that is an indication that they have screwed up big
time in their planning. The only DB that I'm aware of that did a
complete rewrite in the last 10-20 years was Informix with the advent of
SMP technology, and look what hapopened to them.
I hope you are not implying that DB2 has had a major architectural
change in the last 10 years as it simply hasn't (indeed it's still based
on techniques pioneered over 40 years ago, such as shared nothing, read
locks, aries etc).
Go with the latest not the
late.
Go with the proven not the unproved. Leading edge not bleeding edge. You
are a silly person.
Interesting too that DB2 is morphing very rapidly, responding to
what customers want. This should be a big checkbox no matter what your
choice. You won't need the grid unless you're part of the SETI project.
By all means please continue to avoid the grid. Do so with a fervour,
and by all means base your technical analysis of products based on a
scan of a book in a book store, and your own personal feelings about a
single person.
Not for you is any interest in low cost computing, or the practical
application of the principles of consolidation, commoditization,
standardization and automation to Information Technology.
The grid absolutely does not and should not have a place in your future.
BTW, Darwin was absolutely correct.You might want to scan "The Origin of
Species" the next time you are in a book store.
Daniel Morgan wrote:
You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.
But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.
Jim Kennedy wrote: So I guess years of using and having experience with Oracle, DB2, Ingres,
Sybase, Sql Server, XDB, SQL Base (Centura), Btrive, dBase (padadox,
CLipper, Foxpro),my SQL, Isam and others is just too narrow an experience.
I as far as I remember Goob is a pile of mess of buggers. At least my kids
say so.
Jim
boogers not buggers.
Goob would be goobers, etc.
Again, thanks for your comments. According to your list, most of the databases
you have had experience with are gone and practically forgotten. Most if not
all of them are very simple in comparison to Oracle, not even in the same category.
Paradox is gone. Foxpro lives on, and .dbf files live on in many phone dialers to this
day. Sybase is trying to make a comeback, SQL-Server is so not interesting because of
Sybase. The only one you mentioned with any glamour would be Ingres.
Interesting to have read a little of that book I mentioned, "SOFTWAR", about Ellison,
and what he thought of Ingres--he was very impressed according to the author, with
Dr. Stonebreaker and how good the engineering was in Ingres. It's enough of a
statement to get me interested in Ingres again--there may be something there to
use in a business context--and certainly for the person with the original post
to this thread.
Thanks Jim, I'll be waiting for your review of Empress, the only one you
seemed to have missed--er well their was Progress too.... so many players,
so little left to choose from.
"Data Goob" <da******@hotmail.com> wrote in message
news:Zs***********@fe55.usenetserver.com...
Jim,
Thanks for your comments. I disagree that I'm 'completely' wrong, but it
doesn't really matter, I'm not using Oracle. Oracle is a beast of a pig
all the way around, but you would only know that if you used something
besides Oracle. Oracle has excellent marketing, pay no attention to the
man behind the curtain.
Thanks!
Jim Kennedy wrote:
Mark Townsend wrote: Data Goob wrote:
Interesting viewpoints about Oracle vs IBM.
I recently scanned through the autobiography about Larry Ellison called
"SOFTWAR", at my local bookstore. Very interesting book, and full of a
lot of interesting information, and lots of innaccuracies. The telling
point at least to me was about Larry and what the company is all about.
( You can find it in the business book section under "arrogance" 8-)
So your comments are based on a brief scan of a 500 page book in a
bookstore, written by a journalist about a single person, and on that
you determine the usefulness of the technology produced by over 40,000
other people ? Great analysis.
http://www.urbandictionary.com/define.php?term=goob&r=f
They don't have Data Goob, only Goob, so you missed! ;-)
In the book they mention that Oracle is more about applications than the
database. If you have an application that requires Oracle, you will
indeed
have to use Oracle. But I would caution against using Oracle as a
database
choice especially in light of where your people are in skills. In
Larry's
own words they indicate the direction of the company has less to do with
being a database company and more to do with applications.
Complete and utter bullshit. You have absolutely NO basis for your
characterization, yet you make it. Why ?
It was based on experience?
Larry is in
his own words more interesting in winning than providing a product that
is indicative of being a good technology choice. Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements.
You obviously have no idea how the grid applies to business. Note that
one of the foremost proponents of the grid architecture is indeed Ford.
Enlighten me on the grid. I'm getting my SETI screen-saver fired up, and
turning on the Lava Lamp. LOL.
Oracle will be a big nut
to crack in an organization that has never used a relational database.
2 days is all it takes - see
http://download-west.oracle.com/docs...b10742/toc.htm
Scan it online.
I'd like to but what's the point?
IBM has an excellent set of databases, and the company can also sell you
a complete end-to-end solution, meaning hardware as well as software.
They cannot actually sell you any business applications, can they. A
complete end-to-end as long as you take the actual business out of the
definition of the solution (you know, HR, General Ledger, Mnaufacturing,
Supply Chain etc). You are a silly person.
Personal attacks aside...is there a problem running software from another
vendor? According to Ford they weren't impressed with Oracle enough after
all that work and wasted money. Oracle certainly lost on that one.
I
have seen the latest results on benchmarks and both Oracle and DB2 are
at the top. IBM will dominate the landscape with Power5 hardware, and
Power6, etc. with loads of innovation that I do not see coming from
any other vendor.
Correct - IBM hardware is very,very good. Both Oracle and DB2 run very
well on it.
However, hardware innovation does not = software innovation.
It's interesting that Oracle has to partner with HP and Superdomes and all
that but looks like the ole Superdome is toast along with Sun. Sun is done
too with the hardware. Pretty soon Sun will have to start selling furniture
or home appliances just to stay relevant. Maybe Home Depot can pick them
up and help build the Java-enabled home. LOL.
DB2 is NOT particulary innovative software, and indeed, a large part of
the DB2 software devleopment plans are to provide features from other
databases to aid in migration from SQL Server and Oracle - witness the
addition of both indentities and sequences in the last couple of
releases. The latest release of DB2 is a prime example of this - there
is very little that is actually innovative (or even new) in the 8.2
release.
Can't argue with that, but it's nice to know DB2 is a great choice out there
so that I don't have just MS-SQL or Oracle to choose from. Kinda like the
three bears story, DB2 is juuuuuuuuust right.
It is indeed important to make the choice in the right context as others
have indicated. Should it really be Oracle vs DB2 as a database choice?
Or in your case DB2 vs SQL-Server or Ingres or MySQL or Informix? These
are database products that would probably be more suited to a comparison
today. Incidentally Oracle has not had a major architectural change in
its engine since V7, and that was what, 10+ yrs ago? SQL-Server hasn't
had a major upgrade in what 6 yrs? DB2 has been changing rapidly to meet
the market, and so are a few of the others.
You are confusing two things. All databases meet new market
requirements, some faster than others, and none of them should require
major architectural changes to do so. If a database company has required
a major architectural change in the last 10 years to meet new market
requirements then that is an indication that they have screwed up big
time in their planning. The only DB that I'm aware of that did a
complete rewrite in the last 10-20 years was Informix with the advent of
SMP technology, and look what hapopened to them.
I would hardly make that nexis. SMP is interesting in its own right, with
that whole cylce suddenly going through a dramatic change. Power5, Power6, are
putting an end to SMP as we know it. Unisys, god they went and tried to get
into the Wintel Mainframe, and now, two short years later, it's irrelevant.
They wanted "cellular partitioning" but it is so expensive for even a simple
16 CPU machine--a domain that Windows does poorly in. Unisys and Microsoft
thought they could do it with Intel hardware, but it's total crap. Virtualization
yes, it is the new domain, but more to do with software with less emphasis on the
CPU-count. Power5 makes the other players really look toast. Intel is running
out of gas, AMD is eating their lunch, and IBM is going to dominate the CPU channel
going forward. It's not going to happen overnight, but it is happening.
I hope you are not implying that DB2 has had a major architectural
change in the last 10 years as it simply hasn't (indeed it's still based
on techniques pioneered over 40 years ago, such as shared nothing, read
locks, aries etc).
Unless I'm mistaken the clustering and partitioning features of DB2 clearly
are relatively new, in the past few years.
Go with the latest not the
late.
Go with the proven not the unproved. Leading edge not bleeding edge. You
are a silly person.
C'mon Mark, no need to attack me personally. Real Data Goobs use several
database products, not locked into one vendor. :-)
Interesting too that DB2 is morphing very rapidly, responding to
what customers want. This should be a big checkbox no matter what your
choice. You won't need the grid unless you're part of the SETI project.
By all means please continue to avoid the grid. Do so with a fervour,
and by all means base your technical analysis of products based on a
scan of a book in a book store, and your own personal feelings about a
single person.
Thanks. BTW, I didn't buy the book it was priced too high! LOL. Just
like the software.
Not for you is any interest in low cost computing, or the practical
application of the principles of consolidation, commoditization,
standardization and automation to Information Technology.
Now here you score points for muddy water. The grid == SETI screen saver.
We don't need a screen saver in our organization. Thanks. But we are
doing things with low-cost computing that work extremely well without the
screen saver. I realize Oracle has to sell visionary visions, but let's
get our priorities straight--whatever happened to the Oracle PowerBrowser?
LOL.
The grid absolutely does not and should not have a place in your future.
Whew! Thanks for the memo.
BTW, Darwin was absolutely correct.You might want to scan "The Origin of
Species" the next time you are in a book store.
Even the dinosaurs had to eat something. Soon Oracle will be extinct too.
:-)
Daniel Morgan wrote:
You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.
But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.
BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.
Data Goob wrote:
In Larry's
own words they indicate the direction of the company has less to do with
being a database company and more to do with applications.
Complete and utter bullshit. You have absolutely NO basis for your
characterization, yet you make it. Why ?
It was based on experience?
Who's ?
You obviously have no idea how the grid applies to business. Note that
one of the foremost proponents of the grid architecture is indeed Ford.
Enlighten me on the grid. I'm getting my SETI screen-saver fired up, and
turning on the Lava Lamp. LOL.
Presuming that this was not a rhetorical question, the argument goes
something like this.
Silo's of computing are bad. Seperately configured systems for
individual workloads are bad - high cost, each over worked individually
but under utilized in terms of resources across the company. Labour
intensive. Difficult to integrate, make secure, make highly available.
So as an alternative, consider a grid. As follows
Consider data management software that stores not only characters
numbers and dates, but all your email, all your documents, all your
multimedia, all your spatial, all your XML. Everything digital that you
may care about. Not only that, but can truely do cross domain queries -
for example, a single query that anwsers the question - "Find me all
customers who previously placed but cancelled an order over the web (in
XML), for a product whose shipping instructions mentioned special
handling requirements due to fagility, where those customers are now
with 5 miles of the new store we are just opening"
Place this data on a storage grid based on SAN or NAS storage shared
amongst multiple systems, complete with intelligent software that
automatically manages the data placement to give maximum performance and
availablity for all those systems. The same data management software
that then automatically backs up this data, automatically allows any
change made in error to the data to be undo, automatically mirrors the
data across two or more physical storage grids for redundancy and
disaster recovery. Then add the ability to horizontally manage the
physical storage across the organization simply by adding new disks to
the storage grid and have the storage grid then automatically (and
online) maintain the most optimal data/disk layout. Do this on with any
disk solution, anywhere, and even with emerging low cost ATA technology.
Consider then the database grid - the machines that access the data on
behalf of the applications. Consider a cluster of these machines, all
very low cost commodity hardware, each with 2-4 cpus, intellgently
sharing the workload and access to this data. Have workloads be able to
expand across the physical boundary of a single machine. Have each
workload definable as a level one object in the taxonomy, and be able to
dynamically add or remove machines to and from a workload. Have service
levels definable that determine how one defined workload should be
failed over to other machines in event of an outage. Have service levels
definable that determine the required performance characteristics for
each workload, with the ability to react to an outage in the service by
adding (or removing) more machines. Do this on any hardware, with any
operating system.
Do the same thing at the application server grid level, but now also
include all the web services, BPEL and SOA good geekness that is in that
environment (of which I know little). Have the same service level
definition of a workload that is defined at the storage and database
level apply here as well, for end-to-end monitoring up and down the
stack, and eventual dynamic sharing of the machine resources between the
database and application server layer. Have the same definition of a
user up and down through the entire stack as well. Manage ALL the users
access, security, roles etc in one central location, with ALL other
software using this information consistently - the same Mark Townsend -
from the application login, to the browser cookie, to the app server
connection, to the JDBC connection, to the proxied user identity in the
database telling the system what I can and cannot access.
Then provide built in application level monitoring software that can
start from the end user and trace a representative transaction up and
down the stack - all the way from the browser across the network to the
app server to the Java container to the executed SQL to the the storage
IO. Have defined service levels for these transactions as part of the
workload definition. Automatically alert an administrator if the service
level starts to fail and provide the ability to profile where the
problem is from one end to another, with the ability to step into any
layer in the stack and diagnose the problem using wizards and advisors.
Do this end to end tracing from any endpoint in the network. Then have
the software just do this automatically for you, and simply tell you
what needs to be fixed, by when, and how.
Then provide configuration management software that allows you to define
the standard configuration for any one of these component layers, as
well as your best practice security, HA, performance and deployment
procedures. Centrally manage these configurations, and as new
machines/disks arrives, just blow these configurations out to them and
remotely build the machines. Automatically check every day with the
vendor to see if any urgent patches/fixes are required to YOUR specific
configuration. If so, have them downloaded to the central repository,
and have these blown out to the targets as well. Have the same software
then automatically checks every 24 hours to see that your best practice
configurations have not been bypassed.
Then build a suite of business application on top of this.
The grid is a little more than lava lamps and SETI screen savers. SETI
was all about an organization without money finding ways to borrow
machine cycles from other people. Good for SETI, but not going to happen
for Ford, Boeing etc - Ford is not going to go to GM and say "run this
workload for me, I can't afford to". Instead, commercial grids are
built, not borrowed, and the future of the grid is all about the
practical application of well known consolidation, commodization,
standardization and automation techniques to the problem of deploying IT
solutions more efficiently. The Grid is to IT what the Ford Model T
assembly line was to Manufacturing. And most importantly, you can start
anywhere with this. Each of the advantages is achievable in it's own
right, with it's own individual value prop and ROI calculation. And as
you complete more and more of the jigsaw, over time, the ROI increases,
and increases, and increases.
It's going to be a fun few years.
Mark Townsend wrote: Data Goob wrote:
In
Larry's
own words they indicate the direction of the company has less to do
with
being a database company and more to do with applications.
Complete and utter bullshit. You have absolutely NO basis for your
characterization, yet you make it. Why ?
It was based on experience?
Who's ?
Actually to get you back on track, read through Larry's book, the words are
in the book, not quoting, but close enough, Oracle is more about applications
than databases. ( the book is "SOFTWAR" )
As far as my experiences with Oracle, it is the most expensive database
product on the market, not to mention one of the most complicated.
Now let's move along to your acid trip...
Assuming you are 100% correct about the grid, commodity/utility computing,
SETI, and all that, why on earth would Oracle be relevant in the equation?
As if they are the only ones who figured it out? As if they are the right
choice for that? As if the grid is even relevant...
Smoke some more Mark... break out the bong...
You obviously have no idea how the grid applies to business. Note
that one of the foremost proponents of the grid architecture is
indeed Ford.
Enlighten me on the grid. I'm getting my SETI screen-saver fired up, and
turning on the Lava Lamp. LOL.
Presuming that this was not a rhetorical question, the argument goes
something like this.
Silo's of computing are bad. Seperately configured systems for
individual workloads are bad - high cost, each over worked individually
but under utilized in terms of resources across the company. Labour
intensive. Difficult to integrate, make secure, make highly available.
So as an alternative, consider a grid. As follows
<snipped>
Later that same day...
The grid is a little more than lava lamps and SETI screen savers. SETI
was all about an organization without money finding ways to borrow
machine cycles from other people. Good for SETI, but not going to happen
for Ford, Boeing etc - Ford is not going to go to GM and say "run this
workload for me, I can't afford to". Instead, commercial grids are
built, not borrowed, and the future of the grid is all about the
practical application of well known consolidation, commodization,
standardization and automation techniques to the problem of deploying IT
solutions more efficiently. The Grid is to IT what the Ford Model T
assembly line was to Manufacturing. And most importantly, you can start
anywhere with this. Each of the advantages is achievable in it's own
right, with it's own individual value prop and ROI calculation. And as
you complete more and more of the jigsaw, over time, the ROI increases,
and increases, and increases.
It's going to be a fun few years.
With the drugs you're gettin? whooooo hoooooooo!
Data Goob wrote: I remain jealous of you Daniel for having access to really good weed!
It seems
to have the intended effect. Must be that stuff from Vancouver I heard
about.
I'm about 40 years too old to care what they smoke anywhere.
Anyway since you opened the door...
DB2 is far less difficult to understand and master than Oracle. More
specifically Oracle is the difficult database, whereas DB2 is a breeze to install and
use.
And you say that based on exactly what experience, how long ago, on what
versions based on what training? This sentence is meaningless and you
know it.
Oracle is a collection of disparate pieces of bolt-on software that
requires years
to "master" and lots of people to make it successful.
If you think others are smoking something surely you are injecting
something. What a load of pure rubbish.
This is why it is happy
in larger organizations and completely inappropriate in smaller ones. DB2
has a clearly defined scalability that Oracle has yet to implement.
Which of course explains why it undersells Oracle on Windows and Linux.
Instead
Oracle continues to opt for smoke and mirrors.
Well that and sales.
10g has yet to be proven in the business world as even relevant, much less RAC ( bwaahahaaaa! :-)
Laugh. Thelargest airplane manufacturing company in America is
implementing production systems with RAC for line-of-business apps.
DB2? I'm sure there a few legacy systems laying around. So what
exactly are you laughing about?
I would
say DB2 and SQL-Server are more equivalent in ease of use, but the
differentiator
in DB2 is that it can scale way beyond what SQL-Server can, on low-cost
hardware,
and O/S.
I would say you haven't actually used Oracle in years and are expressing
not technical knowledge but personal ignorance.
Oracle requires a lot of money, time, and hardware, something I would
be very concerned about as a business wanting to be competitive and keep
costs
down.
Oracle licensing starts at $749 (SE1 5 named user license). Take the
needle out of your arm and go to http://store.oracle.com where you can
confirm it if you wish.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Data Goob wrote: Jim,
Thanks for your comments. I disagree that I'm 'completely' wrong, but it
doesn't really matter, I'm not using Oracle. Oracle is a beast of a pig
all the way around, but you would only know that if you used something
besides Oracle. Oracle has excellent marketing, pay no attention to the
man behind the curtain.
Thanks!
Anecdotal inflammatory nonsense lacking in substance. If you have any
actual experience from which to draw the conclusions you have state it!
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
> Actually to get you back on track, read through Larry's book, the words are in the book, not quoting, but close enough, Oracle is more about
applications than databases. ( the book is "SOFTWAR" )
And IBM is more about hardware than databases. Apparently you don't have
an actual point so you just made one up.
As far as my experiences with Oracle, it is the most expensive database
product on the market, not to mention one of the most complicated.
Which speaks volumes about your experience doesn't it. How exactly is a
license for $749 USD expensive?
Now let's move along to your acid trip...
The only acid I'm seeing here is nitric.
Assuming you are 100% correct about the grid, commodity/utility computing,
SETI, and all that, why on earth would Oracle be relevant in the equation?
As if they are the only ones who figured it out? As if they are the right
choice for that? As if the grid is even relevant...
Maybe not the only ones to figure it out. But I a lot closer to the mark
than anyone else. Unless you are one of those that promotes UNION ALL as
database partitioning.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
"Daniel Morgan" <da******@x.washington.edu> wrote in message
news:1093732503.821888@yasure... Actually to get you back on track, read through Larry's book, the words
are in the book, not quoting, but close enough, Oracle is more about
applications than databases. ( the book is "SOFTWAR" )
And IBM is more about hardware than databases. Apparently you don't have
an actual point so you just made one up.
As far as my experiences with Oracle, it is the most expensive database
product on the market, not to mention one of the most complicated.
Which speaks volumes about your experience doesn't it. How exactly is a
license for $749 USD expensive?
Now let's move along to your acid trip...
The only acid I'm seeing here is nitric.
Assuming you are 100% correct about the grid, commodity/utility
computing, SETI, and all that, why on earth would Oracle be relevant in the
equation? As if they are the only ones who figured it out? As if they are the
right choice for that? As if the grid is even relevant...
Maybe not the only ones to figure it out. But I a lot closer to the mark
than anyone else. Unless you are one of those that promotes UNION ALL as
database partitioning.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)
What is really interesting is that this guy is clueless. We have been
using Grid type computing for years in our engineering department to do
builds and QA for our products. But this guy is so behind the curve that he
isn't even aware that some companies were doing this, in a rudimentary form,
back in the mid '80's. We are currently looking at implementing RAC across
multiple applications so we can have redundancy, better load balancing
especially across timezones. As each financial quarter ends it would be
nice to give the order and reporting systems more database priority than
lets say the call center software etc. Or as the day sets and the call
center software needs less database resources - we don't have as many people
in the PacRim - but the datawharehouse loads need more resource. RAC is a
way we could share that resource and not build huge silos.
But hey how do you tell a 17 year old that his elders have more experience.
It is amazing that in 7 years the 17 year old will discover his elders
learned a lot in 7 years. <grin>
Jim
Data Goob wrote:
Actually to get you back on track, read through Larry's book, the words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an address
offline, I'll send it to you. Then you can actually quote chapter and
verse to your heart's content.
Mark Townsend wrote: Data Goob wrote:
Actually to get you back on track, read through Larry's book, the
words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an address
offline, I'll send it to you. Then you can actually quote chapter and
verse to your heart's content.
Thanks but no thanks. I'll rely on my brief encounter with this tour
de force in errors and omissions as having been enough reading about
Larry and his obsessions for a while. It's a bit confusing to me
when it comes to Oracle people, but also Microsoft people as well,
are they passionate about the marketing or the technology? ( I think I
already know the answer, no need to reply. )
Data Goob wrote: Mark Townsend wrote: Data Goob wrote:
Actually to get you back on track, read through Larry's book, the
words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an address
offline, I'll send it to you. Then you can actually quote chapter and
verse to your heart's content.
Thanks but no thanks. I'll rely on my brief encounter with this tour
de force in errors and omissions as having been enough reading about
Larry and his obsessions for a while. It's a bit confusing to me
when it comes to Oracle people, but also Microsoft people as well,
are they passionate about the marketing or the technology? ( I think I
already know the answer, no need to reply. )
Proof, once again - ignorance is bliss. After all, why use proof when
insinuation, innuendo and implication are so useful.
Thanks for the wonderfully amusing thread.
/Hans
In article <5%aYc.71113$X12.14547@edtnps84>, Hans Forbrich wrote: Data Goob wrote:
Mark Townsend wrote: Data Goob wrote:
Actually to get you back on track, read through Larry's book, the
words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an address
offline, I'll send it to you. Then you can actually quote chapter and
verse to your heart's content.
Thanks but no thanks. I'll rely on my brief encounter with this tour
de force in errors and omissions as having been enough reading about
Larry and his obsessions for a while. It's a bit confusing to me
when it comes to Oracle people, but also Microsoft people as well,
are they passionate about the marketing or the technology? ( I think I
already know the answer, no need to reply. )
Proof, once again - ignorance is bliss. After all, why use proof when
insinuation, innuendo and implication are so useful.
Thanks for the wonderfully amusing thread.
/Hans
The original posting asked about the differences and specifically
asked for no flames. Thanks for the thoughts by everyone.
Godwin's Law.
"Mike" <mi***@mikee.ath.cx> wrote in message
news:10*************@corp.supernews.com... The original posting asked about the differences and specifically
asked for no flames. Thanks for the thoughts by everyone.
Godwin's Law.
Anytime someone cross posts in two different (competing) newsgroups, you are
going to get flames, lies, and videotape.
Data Goob wrote: Mark Townsend wrote:
Data Goob wrote:
Actually to get you back on track, read through Larry's book, the
words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an
address offline, I'll send it to you. Then you can actually quote
chapter and verse to your heart's content.
Thanks but no thanks. I'll rely on my brief encounter with this tour
de force in errors and omissions as having been enough reading about
Larry and his obsessions for a while. It's a bit confusing to me
when it comes to Oracle people, but also Microsoft people as well,
are they passionate about the marketing or the technology? ( I think I
already know the answer, no need to reply. )
Away with the facade of caring about truth and accuracy? This is the new
century and if politicans and lawyers can ignore the facts why not you
too is what I take away from your comment.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Daniel,
Did it ever occur to you that you butted into a conversation as an uninvited guest?
( on several different points I might add )
Wouldn't it be better to let Mark speak for himself? He was on a roll and I was
getting some good information into the mind of Oracle marketing.
If you must butt in, show some courtesy and at least have the decency to put your
drink down before ranting instead of spilling it all over people. Dear god man.
Anyway, I do appreciate your passion as well as Marks' but the devil is in the
details where I come from. Marketing is wonderful but eventually Oracle has to
pony up with reality. Sun is going through their reality check, along with SCO,
for Oracle it's just a matter of time. Larry doesn't have a vision for the
future because his vision has come and gone. Once he steps aside the company
can morph, but if he stays too long it'll be the end of it. Sun missed it, SCO
missed it, Unisys, DEC, the list gets longer every day. As Gordon Gecko said,
it's not the survival of the unfittest.
Daniel Morgan wrote: Data Goob wrote:
Mark Townsend wrote:
Data Goob wrote:
Actually to get you back on track, read through Larry's book, the
words are
in the book, not quoting, but close enough, Oracle is more about
applications
than databases. ( the book is "SOFTWAR" )
I have the book. I have read the book. If you like to send me an
address offline, I'll send it to you. Then you can actually quote
chapter and verse to your heart's content.
Thanks but no thanks. I'll rely on my brief encounter with this tour
de force in errors and omissions as having been enough reading about
Larry and his obsessions for a while. It's a bit confusing to me
when it comes to Oracle people, but also Microsoft people as well,
are they passionate about the marketing or the technology? ( I think I
already know the answer, no need to reply. )
Away with the facade of caring about truth and accuracy? This is the new
century and if politicans and lawyers can ignore the facts why not you
too is what I take away from your comment.
Data Goob wrote: Daniel,
Did it ever occur to you that you butted into a conversation as an
uninvited guest?
( on several different points I might add )
Which part of 'you posted to comp.databases.oracle.server' didn't you
understand? Did you think c.d.o.server was an IBM DB2 usenet group or
did you think it was an appropriate place for private conversations.
If you need help understanding the public nature of the internet I
would be happy to suggest some local community college classes for you.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Daniel Morgan wrote: Data Goob wrote:
Daniel,
Did it ever occur to you that you butted into a conversation as an
uninvited guest?
( on several different points I might add )
Which part of 'you posted to comp.databases.oracle.server' didn't you
understand? Did you think c.d.o.server was an IBM DB2 usenet group or
did you think it was an appropriate place for private conversations.
The trouble is that most, if not all, of these posts are cross-posted to
comp.databases.ibm-db2 as well, so you will have to expect replies from
people on the ibm-db2 newsgroup as well.
If you need help understanding the public nature of the internet I
would be happy to suggest some local community college classes for you.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 17:45:00 up 1 day, 2:59, 3 users, load average: 4.11, 4.11, 4.09
Jean-David Beyer wrote: Daniel Morgan wrote:
Data Goob wrote:
Daniel,
Did it ever occur to you that you butted into a conversation as an
uninvited guest?
( on several different points I might add )
Which part of 'you posted to comp.databases.oracle.server' didn't you
understand? Did you think c.d.o.server was an IBM DB2 usenet group or
did you think it was an appropriate place for private conversations.
The trouble is that most, if not all, of these posts are cross-posted to
comp.databases.ibm-db2 as well, so you will have to expect replies from
people on the ibm-db2 newsgroup as well.
Exactly. So if someone wishes to communicate in a single usenet group
it is incumbent upon that person to edit the group list. And if they
wish a private communication they should respond to the OP directly.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Daniel A. Morgan wrote: Data Goob wrote:
Exactly. So if someone wishes to communicate in a single usenet group
it is incumbent upon that person to edit the group list. And if they
wish a private communication they should respond to the OP directly.
Sounds good to me. So could DataGoob and you please "take it outside".
This thread has 0 technical content (excluding Mark's strategy post).
I for one am really not interested in watching the two of you bashing
each others virtual heads in. If I want to see that I browse the
"omlet-thread" in c.d.o.s
Cheers
Serge
Hans Forbrich <fo******@yahoo.net> wrote in message news:<CxGXc.19631$A8.18211@edtnps89>...
....Sybase sold their soul to Microsoft by giving them what is now SQL Server.
and all of them, near as i can tell, have sold their souls to
XML Data Storage, thus eviscerating the relational model, and
taking us back to IMS. i hope they're all Real Proud of themselves.
annoyed and distraught,
robert
robert wrote: Hans Forbrich <fo******@yahoo.net> wrote in message news:<CxGXc.19631$A8.18211@edtnps89>...
...Sybase sold their soul to Microsoft by
giving them what is now SQL Server.
and all of them, near as i can tell, have sold their souls to
XML Data Storage, thus eviscerating the relational model, and
taking us back to IMS. i hope they're all Real Proud of themselves.
annoyed and distraught,
robert
I agree. There is a proper place for XML. XML is good. But it is
no more the solution to every problem than is a nail.
--
Daniel A. Morgan
University of Washington da******@x.washington.edu
(replace 'x' with 'u' to respond)
Daniel Morgan wrote: robert wrote: and all of them, near as i can tell, have sold their souls to XML Data
Storage, thus eviscerating the relational model, and
taking us back to IMS. i hope they're all Real Proud of themselves.
annoyed and distraught,
robert
I agree. There is a proper place for XML. XML is good. But it is
no more the solution to every problem than is a nail.
Who ever talked about throwing away the screwdriver and screws because
the vendors agree that hammers and nails belong into their toolbox?
XML does not spell the end of SQL although I dare the opinion that SQL
is fairly mature.
Cheers
Serge
And I thought I was the only person on the planet that sees anything wrong
with XML. The first time I saw an article espousing the benefits of this
great new tool (some idiot calling it the "new ASCII" - doh!) all I could
see was a bloated pig of a format that looked like it spewed forth from the
mind of a juvenile delinquent. That it has made its way into the DBMS
engines shows that people have more computing resources than they have good
sense.
--
Michael D. Long
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om... Hans Forbrich <fo******@yahoo.net> wrote in message
news:<CxGXc.19631$A8.18211@edtnps89>...
...Sybase sold their soul to Microsoft by giving them what is now SQL Server.
and all of them, near as i can tell, have sold their souls to
XML Data Storage, thus eviscerating the relational model, and
taking us back to IMS. i hope they're all Real Proud of themselves.
annoyed and distraught,
robert This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jan Bols |
last post by:
I've been trying to install Oracle 8.1.7 on a fresh Mandrake 9.1 O.S for
days, but I'm still not able to get it running. I've tried several
install instructions that I found on the internet but no...
|
by: susmita_ganguly |
last post by:
Hi
I am trying to upgrade from oracle 8i to oracle 9i on the same server
..I don't know much abt migration .
Can anyone help me out.
Thanks.
Susmita
|
by: Nick Palmer |
last post by:
Hi all,
Is there a DB2 equivilant to Oracle's DB Link functionality ? I have two
DB2 databases and I need to get access to the tables in one from the other.
In Oracle I would just create a DB...
|
by: Jon Ole Hedne |
last post by:
My Access 2002-application need to work with tables from both Oracle and
Access. To solve this, I want to run some querys on three views in Oracle
and import the results into temporary...
|
by: Chris Botha |
last post by:
The machine is running XP Pro with all the latest service packs, etc. I must
access an Oracle database so I installed the Oracle client stuff. I can
query Oracle from a Windows app, no problem....
|
by: Vinod Sadanandan |
last post by:
All,
Below listed are the new features in Oracle 11g ,please join me in this discussion to generate a testcase and analyze each of the listed features .
Precompilers:...
|
by: Ruslan A Dautkhanov |
last post by:
Hello !
I'm about to install O9i on FreeBSD box.
uname -a:
FreeBSD stat2.scn.ru 5.2.1-RELEASE-p3 FreeBSD 5.2.1-RELEASE-p3 #2:
Fri Apr 23 19:19:43 KRAST 2004...
|
by: Jack |
last post by:
Training Classes for Oracle10g, 9i, 8i
Certification training in Oracle10g and 9i: DBA, Developer,
Discoverer. training conducted at your location worldwide. Courseware
licensing also available....
|
by: Winder |
last post by:
Training Classes for Oracle10g, 9i, 8i
Certification training in Oracle10g and 9i: DBA, Developer,
Discoverer. training conducted at your location worldwide. Courseware
licensing also available....
|
by: sathyguy |
last post by:
when i type the below in my RHEL AS 4's Firefox 1.5
http://appsworld.ncc.com:7777/forms/...&form=test.fmx
iam getting the below error...
The requested URL /forms/frmservlet was not found on...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
