| Gottfried
I have worked with INGRES for 2 years, and now I am RALLY/RDB fun. I will
try to answer some of your questions.
>- They've got something going with Applications By Forms. I'm not particularly
> impressed with it, but the customer's staff tell me it looks much less
> complicated to them than Rally. Needless to say, we never got to do a Rally
> workshop there because they claimed that some of the functionality in their
> application is so tricky that Rally can't do it, external links won't be much
> help, etc. Of course they had examples. I've asked them to check the same
> with ABF, but I'd still like to have comments from those of you knowledgeable
> in Ingres about that.
INGRES/ABF is language oriented, for medium to complex applications one have to
write hundreds and thausends lines of code (in INGRES/4GL called OSL).
At least one customer in ISRAEL start developing with ABF and moved to ADA/RDB
because of this reason. You have better tools (VAXSET,DEBUGGER) to develope
and maintain 3GL code then OSL code.
>- They like the other tools, e.g. the business graphics running on a humble
> VT320. I tried to get somthing a bit more advanced out of it and could not,
> but the expert was not available.
If you refer to INGRES/GBF, it does not give any solution for character cell
terminal (very poor quality). DECGRAPH is much better tool on graphic
terminals. for direct access to rdb you might use TEAMDATA.
>- They like the idea of it having a client-server architecture. They say: of
> course, Rdb with ACMS would be even better, but without ACMS, it's got an
> advantage over Rdb. Does it ? Memory consumption? CPU consumption ?
Client-server architecture is new to version 6.0 and I don't have any
experience, however, if you run several servers on the same machine,
they are not sharing any buffers. In version 5.0 you could share buffers
using global sections, but it was not allways recomended, and mostly
the local buffers were used.
>- They like the idea of it having global buffers. They're primarily an RMS
> shop, so it sounds familiar to them. Does anyone have experience indicating
> whether that's really an advantage?
>- They like the optimizer. They've always been critical of the Rdb optimizer.
> Also they haven't tried Ingres with large databases and complex queries, but
> they are told it's good. So I thought, by the way.
it is true that INGRES optimizer is very good. RDB optimizer in version 3.0
is much better then before. it will not be easy now to form a query that
optimized better with INGRES then with RDB.
>- They like the RMS access through SQL.
I liked it too. RALLY access to RMS gives you about the same functionality.
INGRES/RMS GATEWAY(like RALLY) works only on simple fixed length RMS files.
>All in all, looks like rough times ahead. Can anyone provide me with some
>experience of actually using it, in particular about DB restructuring
>possibilities (remember they were burnt with EXPORT/IMPORT), system management,
>but also about actual, real-life productivity and performance? I've read the
>theoretical material as much as I could lay my hands on, but would greatly
>appreciate additional information.
EXPORT/IMPORT tools of INGRES are very good .COPY command, copydb, unloaddb
gives you much more flexiblity and ease of use then RDB tools.
in all other aspects of RDBMS, RDB is better then INGRES.
Among others you can point out: no space management, no record clustering,
no long unstructured data type, no referential integrity, no monitoring tools
like RDB/RMU, no lock on record level, only one page size (2k).
I hope it helps
Arie Levy
|
| First, I think you need to contact product management about some of the
problems. You may find that some of the areas are addressed in the MNR
of Rdb/VMS. I know of at least two customer comments that are addressed
in some respects. Since you don't mention what their EXPORT/IMPORT
problem was, its hard to tell if there is additional help in that area
that is applicable.
I also know of other work at DEC that addresses some of their problems.
Again, Product Management will (hopefully) be able to help as well.
Now, remember that we also have "INGRES Tools for Rdb". If the customer
wants to use the RTI tools, fine. They can then use Rdb/VMS on VMS
systems and the upcoming (program announced) offering on Ultrix systems.
Same applications, etc.
In terms of technical comparisons, Rdb/VMS blows away Ingres in most
respects. Look at the comparison published in The Buffer as part of
last years DECtp announcement. 90% of the comments still apply to
Ingres V6.x!
|
| Arie,
thanks for your comments, I hope I'll be able to use them.
Hal,
I have the impression that I am aware of most of the developments at DEC that
you allude to, however, I am not prepared to discuss them with the customer,
and I dont't think product management would like me to, at this point in time.
The point is that the account manager messed it up by getting them a test
installation of Ingres, and not just the tools. I believe I'm reflecting
Digital's corporate attitude when I'm saying "the tools are welcome, the
database isn't".
I'm going there today for the "showdown" about the issue. I had contacts with
one of their major technical people over the phone and he seems convinced that
Rdb/VMS is the better database engine, so we'll see. Also, being a CSO, they
are not entirely insensitive to the issue of SW cost...
Regarding EXPORT/IMPORT: they have a �VAXII at a customer's site with a 500 MB
database that they wanted to reorganize. After an initial frustrating
experience trying to do it with TK50s, they copied their database onto a
6340 and tried to do it there. 2 hours to export, and after 5 hours, IMPORT blew
up with "EXCEEDED QUOTA". They'd prefer to spend their nights some other way.
Which, incidentally, is why I believe Rdb/VMS will win: online backup!
Thanks again
Gottfried
|
| Re: .1
>> Among other [Ingres disadvantages] you can point out: ...
>> no long unstructured data type, ...
As far as I know, the Ingres people are touting their "BLOB" data type
which sounds just like our "segmented string" data type. If they are
not the same, could someone explain the differences or possibly how their
implementation differs from ours. Also, is this something new with
Ingres v6.0?
Rick C
|