By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,318 Members | 2,340 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,318 IT Pros & Developers. It's quick & easy.

is Oracle technically better than Ingres ?

P: n/a
Dear friends of database(s),

After 13 years of Ingres, I am now using Oracle.

But is Oracle technically better than Ingres.

I would be much obliged if anyone could shed some light on the above
question.

It would also be helpful if you could 'please' keep your comments on a
technical level.

Regards
Michael Newport
Jul 19 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
mi************@yahoo.com (michael newport) wrote in message news:<63*************************@posting.google.c om>...
Dear friends of database(s),

After 13 years of Ingres, I am now using Oracle.

But is Oracle technically better than Ingres.

I would be much obliged if anyone could shed some light on the above
question.

It would also be helpful if you could 'please' keep your comments on a
technical level.

Regards
Michael Newport


It's been a long time since I did anything with INGRES so I won't say
it's better or worse, because I don't know what technology it uses
now.

I will say that Oracle's Multiversioning makes systems run a lot
smoother than DBMS that uses various forms of locks to conrol access.
It can be more resource hungry, but the ease of use and performance
more than compensates, IMHO.

take a look at the Oracle Concepts manual. You'll learn a lot about
how the system operates and why.

HTH,
ed
Jul 19 '05 #2

P: n/a
"michael newport" <mi************@yahoo.com> wrote in message
news:63*************************@posting.google.co m...
Dear friends of database(s),

After 13 years of Ingres, I am now using Oracle.

But is Oracle technically better than Ingres.

I would be much obliged if anyone could shed some light on the above
question.

It would also be helpful if you could 'please' keep your comments on a
technical level.


Anything that implements SQL sucks. Your question therefore is about the
degree of suckiness exhibited by each product. That's a tough one.

I like Ingres' ease of management. I like the fact that Ingres DDL is
"transactional". I like the ease with which I can create (and destroy) a
new Ingres database. I like the ease with which I can restore and recover
an Ingres database. I also like the look of a lot of what is coming in r3.

On the other hand I like the way Oracle implements the READ COMMITTED
isolation level.

As I implied, I'd rather not have to use either of them. But Ingres is the
least bad IMO.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

Jul 19 '05 #3

P: n/a
mi************@yahoo.com (michael newport) wrote in message news:<63*************************@posting.google.c om>...
Dear friends of database(s),

After 13 years of Ingres, I am now using Oracle.

But is Oracle technically better than Ingres.

I would be much obliged if anyone could shed some light on the above
question.

It would also be helpful if you could 'please' keep your comments on a
technical level.

Regards
Michael Newport


Michael, I have never worked directly with Ingres, but we had the
database here once and the two developers who worked with it liked
Oracle much better. Running the same applications against Oracle
provided more up time and required less database related maintenance.

Oracle has advanced greatly since then. There are two different
independent consulting reports that state that Oracle 10g is easier to
manage than SQL Server.

I have wroked with Oracle, SQL Server, DB2 UDB, and mySQL. I like
Oracle better than the others. I second, Ed's suggestion to look or
better yet read the Concepts manual. It is the place to start with
Oracle.

HTH -- Mark D Powell --
Jul 19 '05 #4

P: n/a
Ma*********@eds.com (Mark D Powell) wrote in message news:<26**************************@posting.google. com>...
mi************@yahoo.com (michael newport) wrote in message news:<63*************************@posting.google.c om>...
Dear friends of database(s),

After 13 years of Ingres, I am now using Oracle.

But is Oracle technically better than Ingres.

I would be much obliged if anyone could shed some light on the above
question.

It would also be helpful if you could 'please' keep your comments on a
technical level.

Regards
Michael Newport


Michael, I have never worked directly with Ingres, but we had the
database here once and the two developers who worked with it liked
Oracle much better. Running the same applications against Oracle
provided more up time and required less database related maintenance.

Oracle has advanced greatly since then. There are two different
independent consulting reports that state that Oracle 10g is easier to
manage than SQL Server.

I have wroked with Oracle, SQL Server, DB2 UDB, and mySQL. I like
Oracle better than the others. I second, Ed's suggestion to look or
better yet read the Concepts manual. It is the place to start with
Oracle.

HTH -- Mark D Powell --


The July 19, 2004 issue of InformationWeek p 46 mentions that after a
decade of neglect by CA who had put their attention on Jasmine that CA
is showing renewed interest in marketing Ingres. The title of the
short article is CA goes open source with Ingres database. The
implication is that CA has a lot of work to do to catch up to other
relational database products.

But how good a database is for you depends a lot on the features you
need. Oracle contains a lot of features that many sites do not use,
but if you need analytical functions then Oracle has them. If you
have very large tables then Oracle has partitoned tables and indexes.
With a warehouse operation you might need/benefit from bitmap indexes.

If you really want to compare databases you have to make a list of
features you need/want and then list what each database offers.

HTH -- Mark D Powell --
Jul 19 '05 #5

P: n/a
look at it this way,

using Oracle 9i, I have now written a batch procedure in PL/SQL that
collects lots of data from various tables, and puts it all into a new
table. I also did the same using Ingres 6.4 some time back using only
SQL, running from a cron job.

In Oracle, when the user runs a report (the next day) from the table,
it is slower than it should be as the 'order by' is done at run time.
It seems that I cannot pre-order the data (though I have tried).

In Ingres I used to do this easily with :-
modify <table> to btree unique on <field1>, <field2>, <field3>

Regards
Michael Newport
Jul 19 '05 #6

P: n/a
mi************@yahoo.com (michael newport) wrote in message news:<63************************@posting.google.co m>...
look at it this way,

using Oracle 9i, I have now written a batch procedure in PL/SQL that
collects lots of data from various tables, and puts it all into a new
table. I also did the same using Ingres 6.4 some time back using only
SQL, running from a cron job.

In Oracle, when the user runs a report (the next day) from the table,
it is slower than it should be as the 'order by' is done at run time.
It seems that I cannot pre-order the data (though I have tried).

In Ingres I used to do this easily with :-
modify <table> to btree unique on <field1>, <field2>, <field3>

Regards
Michael Newport


If your process uses only ANSI standard SQL then if you can build the
report table in Ingress then you should also be able to do it with any
other RDBMS that supports the same level of the ANSI standard. If the
SQL is not ANSI standard but involves extentions then it is subject to
question if the process is pure SQL.

The problem with using the rewriting of an existing peice of code as a
means of measuring a DB is that that code was probably written to work
based on the features of the existing DB. The new target DB may well
be based on different design principles and the code should be
structured differently on the new DB for optimal performance. The
problem is if you are good with the old system you are likely not (yet
anyway) good with the new one. Most people like what they know, and
are not going to like a DB with which they are unfamiliar and
inexperienced.

By the definition of an RDBMS a table is an unordered heap (see Codd).
Applying the sort at run time allows the data to be extracted in
whatever order is needed at the time. But if the report is
constructed such that it logically should be extracted in a specific
order then based on your example you would use an Indexed Organized
Table, IOT, which Oracle provides as an option.

IMHO -- Mark D Powell --
Jul 19 '05 #7

P: n/a
Hi,

Does Ingres R3 will suport ERP's like SAP Siebel et al.

Regards,
Goutam Sengupta

Ma*********@eds.com (Mark D Powell) wrote in message news:<26**************************@posting.google. com>...
mi************@yahoo.com (michael newport) wrote in message news:<63************************@posting.google.co m>...
look at it this way,

using Oracle 9i, I have now written a batch procedure in PL/SQL that
collects lots of data from various tables, and puts it all into a new
table. I also did the same using Ingres 6.4 some time back using only
SQL, running from a cron job.

In Oracle, when the user runs a report (the next day) from the table,
it is slower than it should be as the 'order by' is done at run time.
It seems that I cannot pre-order the data (though I have tried).

In Ingres I used to do this easily with :-
modify <table> to btree unique on <field1>, <field2>, <field3>

Regards
Michael Newport


If your process uses only ANSI standard SQL then if you can build the
report table in Ingress then you should also be able to do it with any
other RDBMS that supports the same level of the ANSI standard. If the
SQL is not ANSI standard but involves extentions then it is subject to
question if the process is pure SQL.

The problem with using the rewriting of an existing peice of code as a
means of measuring a DB is that that code was probably written to work
based on the features of the existing DB. The new target DB may well
be based on different design principles and the code should be
structured differently on the new DB for optimal performance. The
problem is if you are good with the old system you are likely not (yet
anyway) good with the new one. Most people like what they know, and
are not going to like a DB with which they are unfamiliar and
inexperienced.

By the definition of an RDBMS a table is an unordered heap (see Codd).
Applying the sort at run time allows the data to be extracted in
whatever order is needed at the time. But if the report is
constructed such that it logically should be extracted in a specific
order then based on your example you would use an Indexed Organized
Table, IOT, which Oracle provides as an option.

IMHO -- Mark D Powell --

Jul 19 '05 #8

P: n/a
mi************@yahoo.com (michael newport) wrote in message news:<63************************@posting.google.co m>...

<snip>
In Oracle, when the user runs a report (the next day) from the table,
it is slower than it should be as the 'order by' is done at run time.
It seems that I cannot pre-order the data (though I have tried).

In Ingres I used to do this easily with :-
modify <table> to btree unique on <field1>, <field2>, <field3>


In other words, your routine had previously relied on an
implementation quirk/feature/nicety of the Ingres btree structure -
and a quirk/feature/nicety that wasn't guaranteed to continue
indefinitely. And you'd best hope your DBA didn't decide hash or isam
would be a better organisation for your table at some point ;)

The bottom line is simple - if you want your result set in a
particular order, guaranteed, whichever product you're using - it's
time for "order by".

- Tony

(PS. I might be wrong, but aren't there circumstances in Ingres 2.6
where this btree "feature" no longer holds true ? ISTR being advised
not to rely on it any more...)
Jul 19 '05 #9

P: n/a
....so anyway I have not had time to implement the IOT suggestion
(people keep giving me other work !), but its nice to know that I can
do the same thing in Oracle that I used to do in Ingres. So thanks for
the help.

But pre-ordering your data is a handy feature that saves time (during
the day) and hassle.

But getting back to my original question, "is Oracle technically
better than Ingres". I still can not say that it is. I was waiting for
a smoking gun from some Oracle people as to why Oracle is better.

Furthermore I kept having an Oracle "snapshot too old" problem which
meant that after weeks of studiously putting my SQL query together, I
am now having to split it up again. Something to do with the query
taking too long.

regards
Mike
Jul 19 '05 #10

P: n/a
mi************@yahoo.com (michael newport) wrote in message news:<63*************************@posting.google.c om>...
...so anyway I have not had time to implement the IOT suggestion
(people keep giving me other work !), but its nice to know that I can
do the same thing in Oracle that I used to do in Ingres. So thanks for
the help.

But pre-ordering your data is a handy feature that saves time (during
the day) and hassle.

But getting back to my original question, "is Oracle technically
better than Ingres". I still can not say that it is. I was waiting for
a smoking gun from some Oracle people as to why Oracle is better.

Furthermore I kept having an Oracle "snapshot too old" problem which
meant that after weeks of studiously putting my SQL query together, I
am now having to split it up again. Something to do with the query
taking too long.

regards
Mike


Mike, sometimes you get a "snapshot too old" because your rollback
segments really are too small. How large are your segments in
relation to the amount of data (include index changes) you are trying
to change. Another common cause is too frequently committing during a
process that reads and updates the same table.

Unlike say DB2 UDB which says to commit often Oracle is designed so
that you should do large amounts of work between commits if concurrent
access requirements allow. If your are updating then OLTP activity
against the same table limits how long you want to hold a modified row
while inserts have no such concurrent activity and can be held for a
longer period without affecting any other session.

Also as you mentioned speeding up the processing of the query will
also reduce the chance of a snapshot too old error if the cause of the
problem is other sessions changing and committing data you need in
very small transactions. How does the explain look? Does the join
order appear to be the best order? Is the join method the best choice
for the data in question? Are you dealing with skewed data values?

If you are using an UNDO tablespace instead of manually configured
rollback setting the undo_retention period to be longer may help you
out.

HTH -- Mark D Powell --
HTH -- Mark D Powell --
Jul 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.