Conference ulysse::rdb_vms_competition

    Rick,
    
    Product features are good. BUT don't forget PRODUCT SERVICE features
    that can provide strong leverage for product sales, for example:
    
    o 24x7 Telephone support 
    
    o On-line info. services with known info. on problems, workarounds, and
    programming examples illustrating the use of Rdb/VMS features
    
    o Technical training in all aspects of Rdb/VMS available at 130
    locations world-wide from 4,000 training specialists, and through
    text-based and computer-aided self-paced instruction
    
    o Consulting and project services from Business Needs Analysis and
    Enterprise data modelling through design, implementation and operation
    to help ensure the most effective application of technology to the
    solution of our customers' business problems
    
    I'm sure that others can improve and add to this list (please, be my
    guest!)
    
    Oh, and please post a pointer to whatever you produce, as soon as you
    can, even in draft form ... I could have used it this weekend!
    
    - Larry,
    In_proposal_frenzy_mode.

A couple that come to mind:

1) SQL Module Language support -- we *really* ought to make more of this than
we do.  I was thinking of writing an article about why module language is 
better than embedded...

2) Totally FIPS-127 compliant, with all host languages and including SQL module
language.   In this area, Oracle has announced that they are compliant, but 
only with V7, I believe, which is not yet shipping  (but then again, I think we
have yet to ship our 100% compliant version, too;  however, ours will be a
normal new version in a progression of versions, while Oracle's V7 is, I 
believe, a new implmentation).  To my knowledge, Ingres hasn't submitted
themselves to NIST testing, probably because they couldn't  come close.
Don't know about Sybase, but I have heard that they are far from compliant.

3) When we include extensions to ANSI/ISO SQL89, we try to make them, where
possible, ANSI/ISO SQL2 compliant.  Other vendors just do their own thing --
Oracle's many SQL functions, for example, most of which will never be standards
compliant.  Digital has been very active in the SQL2/3 standards process.

Hope that helps...

Bryan

I will be glad to add anything to the document you can think of - I don't have
much exposure to the 'services' end of the product, but it certainly sounds like
a subject that fits in line with the goals of the document...

As soon as a draft is available, I'll publish a pointer here, so you can review
it.

Rick

A few others...

The depth of the static optimizer and the *dynamic* optimizer...

I believe that the competition (Oracle, Ingres) have some flavor of static 
optimization.  It sticks in my head that Ingres does have a value based 
optimizer that actually looks at the data values when a retrieval strategy 
is determined (however, I'm not positive about this).  I believe that both
of their retrieval strategies are stored and require manual intervention to 
re-create while Rdb's does not.

As far as I'm aware of nobody has a concept like the dynamic optimizer that 
tries different retrieval methods while the data is being returned and 
dynamically selects the most optimum method.  Means that while executing 
the exact same DSRI compiled request for 2 different queries, two different 
retrieval strategies may be determined....

>optimization.  It sticks in my head that Ingres does have a value based 
>optimizer that actually looks at the data values when a retrieval strategy 
>is determined (however, I'm not positive about this).  I believe that both
>of their retrieval strategies are stored and require manual intervention to 
>re-create while Rdb's does not.

Yes, the Ingres optimizer bases its decsisions on intimate knowledge of data
distribution in the various tables, so it typically did come with better query
plans than rdb did before the days of the dynamic optimizer. However the Ingres
approach has serious limitations:

- someone (the DBA) must make sure the statistics are kept up to date. This is
not done automatically at run time, but by running a special tool at regular
intervals. You can guess this does not come for free: at the minimum it means
scanning the complete database (maybe multiple times if you keep statistics on
multiple columns). And the database is locked when this takes place. Again you
can see that this works well for small to medium databases - but it is a killer
for multi-gb databases. Not to mention the disk and memory space needed to keep
those stats (but you can control the level of detail with which the stats are
taken).

- To get the benefits of statistics, you must recompile the query for each
execution ... which causes extra overhead.

- When no stats are available, the optimizer works just like the rdb static
optimizer - it uses fixed assumptions for selectivity factors, costs ... I
don't know how well the ingres optimizer in this mode compares to the rdb
static optimizer, but I suspect it does not do as well. The Ingres reps insist
on always using some level of statistics.

On the other hand, the dynamic optimizer does not need to get told before hand
about what data is in the database ... It finds that out dynamically at run
time from the real data (not some old snapshot) and adapts its behaviour
automatically - and the query don't need to be recompiled for each execution!

Now, make your own judgement. Which approach is better ?

/albert

> Now, make your own judgement. Which approach is better ?

Be aware that I am NOT looking for features that are necessarily *better* than
our competition - that is for our customers to decide.

Rather, I am looking for features that are DIFFERENT from the competition.  I
just want to be able to present the facts in a manner whereby the customer 
understands what the differences are and can determine if the difference affects
the application or not.

Rick

�      <<< Note 1072.6 by NOVA::NOVA::R_ANDERSON "My timing is Digital." >>>

�Rather, I am looking for features that are DIFFERENT from the competition.  I
�just want to be able to present the facts in a manner whereby the customer 
�understands what the differences are and can determine if the difference affects
�the application or not.

Rick,

Point taken... I'll have to admit that I think that *our* optimizer is 
better, but as far as different, the Rdb static/dynamic approach is 
different than the Oracle/Ingres compiled approach... :)

Below I have attached the "preliminary" outline for the "Rdb Product
Differentiation" document (judging by the number of topics, this is going to be
a "document" instead of a "paper" :-).

The topics are listed in no particular order.

Please feel free to make additions, deletions, changes, suggestions, gripes,
etc!  I expect that each "topic" will be a 2-3 page chapter in the document;
I would like to keep each chapter under 2 pages, but I do not expect to be
able to do this in all cases.

Rick

------------------------ cut here --------------------------

Rdb/VMS Product Differentiation Features

1.  Buffer Management.
    1.  Local Buffers.
    2.  Global Buffers.

2.  Journalling.
    1.  Separate RUJ and AIJ files.
    2.  Group Commit.
    3.  Recovery from loss of non-shadowed AIJ files.
    4.  Dynamic Commit-to-Journal Optimization.
    5.  Per-User Transaction Checkpointing
    6.  AIJ File Compression/Optimization.

3.  Cluster Support.
    1.  Cluster failover support.

4.  Access Methods.
    1.  Btrees.
    2.  Hash Indexes.

5.  Locking Methodologies.
    1.  Adjustable Locking Granularity (Lock Demotion).
    2.  Carryover Locking.

6.  Database Integrity.
    1.  Full Database Verification.
    2.  Pro-active Monitor.

7.  7-by-24 Operations.
    1.  True online database backup.
	1.  Full.
	2.  Incremental.
	3.  By-Area.
    2.  True online database restore and recovery.
	1.  By-Area.
    3.  Online database restructuring.
    4.  Online performance monitoring and tuning tools.
	1.  Database Statistics.
	2.  DecTrace.
	3.  RdbExpert.

8.  Storage Area Support.
    1.  Multiversioning.
	1.  Snapshot Files.
    2.  Multiple Storage Formats.
	1.  Mixed AND Uniform Format Storage Areas
    3.  Compression.
    4.  Dynamic Space Allocation.

9.  Concurrent Release Capability.
    1.  Rolling Upgrade.

10. Integrated Data Dictionary Support.
    1.  Common Digital Product.

11. Standards Adherence.
    1.  Member Transaction Processing Council (TPC).
    2.  Full ANSI-SQL/NIST compliance.
    3.  FIPS-127 compliance with all languages, including SQL module
	language.

12. Architecture.
    1.  Symmetrical Multiprocessing.
    2.  Client/Server via ACMS.

13. Service and Support.
    1.  Customer Service.
    2.  Training.
    3.  Consulting.

14. Integrated End-User Tools.
    1.  VaxRally.
    2.  DecDecision.
    3.  VAX Datatrieve.

15. Performance.
    1.  Fastest (Performance).
    2.  Cheapest (Price Performance).
    3.  Query Optimizer.
	1.  Dynamic Optimizer.
	2.  Static Optimizer.
    4.  SMP Scalability.
    5.  Cluster Scalability.

16. Data Distribution and Replication.
    1.  VAX Data Distributor.
    2.  AIJ Files.

17. Internationalization.
    1.  Multi-National Character Sets and collating sequences.
    2.  MIA Compliance.

18. Multiple Data Manipulation Languages (DML).
    1.  ANSI-SQL.
    2.  RDO.

19. Security.
    1.  C2 Compliance.

20. Data Partitioning.
    1.  Horizontal by hash index.
    2.  Horizontal by btree index.
    

    I know this is late, but here are my thoughts:

    This document looks like it will be a good technical description.  Have
    you considered also doing a management-level white paper?  It seems
    that management & users are getting more involved with the choice of
    database these days but are not interested in the techie-info. How
    about something like:
    
	- How Rdb is open
	- Reduced personnel cost with Rdb
	- Performance (very simple discussion)
	- How Rdb protects your data
    
    I am working on something like this; I will post it when & if I get it
    finished.

    Also some thoughts on your topics:

>>12. Architecture.
>>    1.  Symmetrical Multiprocessing.
>>    2.  Client/Server via ACMS.

    Also client/server via SQL Services and DAL


>>14. Integrated End-User Tools.
>>    1.  VaxRally.
>>    2.  DecDecision.
>>    3.  VAX Datatrieve.

    Also DECquery/Win, DECquery/VMS, DECquery/U*, DECreport, InstantSQL,
    etc.

>>18. Multiple Data Manipulation Languages (DML).
>>    1.  ANSI-SQL.
>>    2.  RDO.

    Many customers consider this a bug, not a feature.

	--------------------

    I think an "Open" topic is needed.  These days, this is usually the
    first topic and also the end of the discussion if you can't address it.
    Should discuss open interface for 4GLs, DOS, Windows, etc; RSVP.
    
    	Al