Conference ulysse::rdb_vms_competition

    SYBASE have their window-based tools collectively call the 'DataToolset'
    and claim these boost programmer productivity.
    The DataToolset is 4GLish but seems to be a lot of 'pick & point'
    to get anything defined.
    They have a report writer as well which takes an SQL query & builds
    the report from that.
                                                            
    

    
    Yes,
    
    The customer reckoned that the 'reportwriter' was just a collection
    of SQL procedures and that the 4GL environment was restrictive enough
    to cause them to have to resort to a lot of 3GL.
    
    Ken

Note how well Rdb/VMS does on these :

    1) No VAX BASIC support.

Rdb/VMS DOES have this.
    
    2) No real reportwriter

Rdb/VMS does NOT have this -- you have to buy Datatrieve or RALLY, or Reporter,
or ... (expensive, and not well integrated)
    
    3) No 4GL development, they reckon they would have to write a lot
    of 3GL code.

Rdb/VMS does NOT have this -- you have to add 3rd party products. (Expensive
and not well integrated)
(Of course, you need to define what you mean by 4GL; some people talk about
SQL as being 4GL; if it is (and I don't think so), then our language is, too.
Perhaps Teamdata or Rally might be considered 4GL by the customer, and then
maybe not). 


The point is that while SYBASE doesn't do too well on these, neither does
Rdb/VMS.  My belief is that DBS needs to work much harder on these areas, and
provide integrated tools, rather than a collection of different products.
Unfortunately, while SYBASE (and ORACLE and INGRES, and ...) can concentrate on
these, we have not only the technical problems, but we also have to deal with
turf issues and politics.  The problems of being a large company... 

      I'll dispute .3.
      Rdb/VMS gives a customer the option of choosing appropriate 4GL
    tools (Rally/Teamdata, SMARTSTAR, PowerHouse, Focus, Intellect,
    etc.). If necessary, multiple tools can be used on the same database.
      No, the 4GL tools are not included with Rdb. But Sybase, Oracle,
    Ingres are VASTLY more expensive than a combination of Rdb and an
    appropriate 4GL.
      Most large commercial customers need more than one toolset. DEC's
    approach allows them to have multiple toolsets with a common data
    storage architecture. This strikes me as a much better approach
    for the customer. It also means we have to be very careful in
    competitive positioning.
    ---- Michael Booth
      

	As a matter of interest, IBI recently announced that they were
	looking for field test sites for their FOCUS - SYBASE interface.

	Andrew.

    re: .3
    
    I'll dispute Brian too.

>>        2) No real reportwriter

>> Rdb/VMS does NOT have this -- you have to buy Datatrieve or RALLY, or Reporter,
>> or ... (expensive, and not well integrated)
    
>>    3) No 4GL development, they reckon they would have to write a lot
>>    of 3GL code.

>> Rdb/VMS does NOT have this -- you have to add 3rd party products. (Expensive
>> and not well integrated)
>> (Of course, you need to define what you mean by 4GL; some people talk about
>> SQL as being 4GL; if it is (and I don't think so), then our language is, too.
>> Perhaps Teamdata or Rally might be considered 4GL by the customer, and then
>> maybe not). 
    
    DEC is weak in the report writer space but we do have a heap of 4GL
    products available both from DEC and 3rd parties.  As for expense,
    we're pretty reasonable compared to the competition. As for
    integration, I'd give us a C+. DSRI gives 3rd parties better
    integration than with other Databases. I hear Oracle customers
    complaining about report writing too. 

    For want of a better place, I'll stick these points here.  Friends
    of mine at a site that went SYBASE have been passing back some points
    that they don't like about it.  I will pass on a few of these.
    
    1. When stored procedures are stored in the database, anybody who
    has access to execute them, also has access for examining them.
    This potentially gives away the store, with regards to Security.
    
    2.  When APT-SQL and APT-FORMS are included into the database for
    storage, the same security risks will exist for them as well.
    Currently they are stored on disk as text files, available for viewing
    from anyone who knows where to look.
    
    3. Triggers (that novel method for ensuring referential integrity)
    are not nested.  This means that update, store or delete operations
    performed from within a trigger are not themselves checked by other
    triggers which may be applicable.  Bye bye possible checks on database
    integrity.
    
    4. My own argument in triggers being the only way of preserving
    referential integrity is this:  You can either be told that your
    application must delete more records to maintain integrity, or you
    can have a trigger do it automatically for you (even if you didn't
    want to delete all of the database automatically).  Which do you
    prefer?                                  
    
    5. The product has been found to be very unreliable in both the
    back and front ends.  SYBASE promised a maximum of two releases
    a year and this year they are already up to 4.  The current set
    of release notes lists over 200 problems, gotchas and workarounds
    with the current release.
    
    6. SYBASE may be trying to compete with Oracle in the futures market.
    Any weaknesses which we have pointed out to date, are always met
    by the announcement that they will be fixed or 'improved' in the
    next release or at the very worst the release after that (next year?).
    
    7. The SYBASE forms tools were found to be very primitive by my
    clients who are trying to build commercial products.  They are now
    testing VAXFORMS, CDD+ and other products, in search of greater
    productivity.  Guess what doesn't work with SYBASE?  I am hoping
    that we may blow away this irritant soon.
    
    I would love to see some more SYBASE knockoffs listed hear, so lets
    hear from everybody else soon.  And please, remember to use keywords!
    
    							Neil Johnson
    							638-6922

After attending a recent SYBASE presentation in Sydney and
talking to the SYBASE "guru" from the U.K. here are a couple of
comments.

The presentation was pretty slick and emphasised that;
o  SYBASE is a second generation DB (Rdb is obsolete?)
o  Investors include Apple, TRW, and Ashton Tate
o  They seem to have agreements with everyone in the Computer Industry
o  SYBASE is a "High-Performance Distributed RDBMS"
o  SYBASE is 24X7, hence, why Stratus uses SYBASE in SQL2000
o  They support 30 users per MB of main memory
o  Their TP1 (industry standard?) was impressive

They also made lots of noise about about triggers, stored
procedures, and how they can dynamically restructure the DB.

In the Corporate Profile (Nobody knows who they are) they stress
how the company has the cream of the DB world's designers and
builders. 

They demonstrated FASTBUILD which is their 4GL application
builder (� la RALLY) and this was the "Star" of the show. It was
emphasised how you can build entire applications using FASTBUILD
without writing code.


However, they didn't say anything DIFFERENT about what their
database did that actually made it `better' than the rest. I
would be seriously concerned about the integrity of the DB if I
were a customer. The product has much maturing to do.

Some of the guru's comments were; 

o They achieve concurrent (multi-threaded) DB activities by using
  Degree-2 consistency. "With TP Applications you don't need
  degree-3" was the justification. For SYBASE to implement degree-3
  they need to use a HOLD qualifier in their TRANSACT-SQL and this
  forces single-threaded DB activity. 

o VAXcluster support is achieved through a `companion server'
  which is the database server on another node that has a deadman
  lock (the only time they use the distributed lock manager) on the
  database server. Only one server is active at a time. Should a
  node crash then the companion server takes over, however, you
  could lose a few of your transactions in the process (because of
  the way they keep as much in memory as possible at any time to
  cut down on I/Os). 

o There MAYBE windows where your application can't tell if a
  transaction has been committed or not, and you may need to
  re-apply the transaction (see previous comment).

o They do not need performance tuning tools because SYBASE is
  optimised for minicomputers. This sounds like they don't have any
  performance monitoring or tuning facility!

o The claim to be vendor of OLTP but they do not have a TP
  Monitor as such. They like to push workstations as the front end
  so they are not worried about multi-threaded forms agents. Just
  think of all those DECnet links to support hundreds of users. 

The "guru" actually did a good selling job and could talk 
easily about ORACLE, INGRES, and Rdb, all at great depth.


If you compete against them then you might need to take
along TP and Rally people.

Regards,
Mark

After attending a recent SYBASE presentation in Sydney and
talking to the SYBASE "guru" from the U.K. here are a couple of
comments.

The presentation was pretty slick and emphasised that;
o  SYBASE is a second generation DB (Rdb is obsolete?)
	> can't argue. rules not stated, can say the same for Rdb

o  Investors include Apple, TRW, and Ashton Tate
	> ditto for Rdb/DEC

o  They seem to have agreements with everyone in the Computer Industry
	> everyone in the insustry seems to have agreements with DEC.
	> Seen a CMP/SCMP/... book lately

o  SYBASE is a "High-Performance Distributed RDBMS"
	> as is Rdb

o  SYBASE is 24X7, hence, why Stratus uses SYBASE in SQL2000
	> Rdb is 7x24, neither is 7x24x365

o  They support 30 users per MB of main memory

o  Their TP1 (industry standard?) was impressive
	> TP1 is not industry standard.  Rdb/VMS *FULL* debit/credit
	> is very impressive.  In their TP1 numbers they never wrote
	> there own log/journal file to disk.

They also made lots of noise about about triggers, stored
procedures, and how they can dynamically restructure the DB.
>
> Triggers are great, I wish Rdb had stored queries
>

In the Corporate Profile (Nobody knows who they are) they stress
how the company has the cream of the DB world's designers and
builders. 
>
> The same group that couldn't set the industry on fire with the BL machine?
> Legends in their own minds. 
>
They demonstrated FASTBUILD which is their 4GL application
builder (� la RALLY) and this was the "Star" of the show. It was
emphasised how you can build entire applications using FASTBUILD
without writing code.
>
> you can do the same things with rally and about 100 other CMPs software
>
However, they didn't say anything DIFFERENT about what their
database did that actually made it `better' than the rest. I
would be seriously concerned about the integrity of the DB if I
were a customer. The product has much maturing to do.

Some of the guru's comments were; 

o They achieve concurrent (multi-threaded) DB activities by using
  Degree-2 consistency. "With TP Applications you don't need
  degree-3" was the justification. For SYBASE to implement degree-3
  they need to use a HOLD qualifier in their TRANSACT-SQL and this
  forces single-threaded DB activity. 
>
> ask any mis manager if they want degree 2 or 3
> also ask about how they journal

o VAXcluster support is achieved through a `companion server'
  which is the database server on another node that has a deadman
  lock (the only time they use the distributed lock manager) on the
  database server. Only one server is active at a time. Should a
  node crash then the companion server takes over, however, you
  could lose a few of your transactions in the process (because of
  the way they keep as much in memory as possible at any time to
  cut down on I/Os). 
>
> I don't like the loosing a few transactions part, but you should
> remember that their archetecture runs everywhere so there are reasons
> why the would not run optimally in a cluster.  Running on multiple HW/SW
> platforms is a STRONG message.
>
o There MAYBE windows where your application can't tell if a
  transaction has been committed or not, and you may need to
  re-apply the transaction (see previous comment).
>
> optimized for tp?
>

o They do not need performance tuning tools because SYBASE is
  optimised for minicomputers. This sounds like they don't have any
  performance monitoring or tuning facility!
>
> Thats right.  They have monitoring tools. At least they didn't when
> when I looked at them.
>

o The claim to be vendor of OLTP but they do not have a TP
  Monitor as such. They like to push workstations as the front end
  so they are not worried about multi-threaded forms agents. Just
  think of all those DECnet links to support hundreds of users. 

The "guru" actually did a good selling job and could talk 
easily about ORACLE, INGRES, and Rdb, all at great depth.


If you compete against them then you might need to take
along TP and Rally people.

Regards,
Mark

RE: .8

	What was the "guru's" name - I know of someone who joined Sybase from
Digital when they set up in the UK last November. He was very good technically,
but had a chip on his shoulder about Rdb after getting burnt (V1.1-2.1) on a 
large internal project (learning pains...)

Steve

Just to confirm - the guy that went to Australia was the ex-Digital employee
that I was referring to. He must be working hard to have become a "guru" inside
10 months!

As I say, he had a hard time with an Rdb project (if his manager had stuck him
on a couple of courses - it would have helped) and is very derogatory about it.

Otherwise he's a sensible guy and was a good friend of mine during his time
here.

Steve

    I have a customer that is considering RDB and SYBASE.  Unfortunately,
    certain members of the customer's evaluation group have swallowed
    SYBASE's marketing pitches.  I hear the integrity of SYBASE questioned
    a lot.  Now, my customer (drug company) needs to present its data to 
    the federal government for approval.
    
    Does anyone know if there are government approvals for DB products
    in environments such as defense, drugs, etc?  It seems to me that
    if SYBASE has any real integrity problems that the Feds would not
    accept data from a SYBASE database concerning a drug study.
    
    Can anyone shed some light on this?  And, by the way, the discussion
    here has been very helpful to me in filtering the marketing hype
    of SYBASE.  Thanks.
    
    
    Dick

I've never heard of a data integrity problem per se.  However, SYBASE
does have a number of ways that allow you to intentionall bypass some of
the integrity checks.  For example, their high-speed load bypasses the
integrity checks (its up to you to ensure that the data is correct
beforehand).  There is more on this in The Buffer special issue on the
DECtp announcement.  An electronic copy can be found in the Rdb
conference, somewhere in the replies to the first few notes.

Depends on the application that they are using it for.

The main problem that I have with Sybase is that their performance claims 
are not real.  They claim many-many TPS, all data in memory, no journaling to
disk, unable to rollback a single transaction.

If you want to make data integ. an issue, make Sybase tell them how they
handle RUJ and AIJ.  Make Sybase explain the differences between degree 1
2 and 3 consistancy and then ask them what level they provide.

    I attended the same demonstration/presentation as Mark in 58.8.
    The guy's name is Andy Symonds. Is this the person you were thinking
    of?
    
    The FASTBUILD product is very similar to Rally, and is actually
    based on a Dutch product called Information Builder. SYBASE claimed
    to have a special relationship with them, but it didn't sound as
    if they had actually bought the company. Does anyone have more
    information on them?
    
    Support for SYBASE in Australia is almost non-existent, they had
    to fly Andy from the UK to demonstrate the product. What is their
    support like overseas?
    
    By the way, the version they demonstrated was V3.2 - I'm not sure
    of the differences between this and previous versions. It seemed
    that V3.2 was hot off the press - but they're only new in Australia
    so I don't know a lot about them.
    
    
    Cheers,
    
    Julie

RE: -1

Yes, I was referring to Andy. 

I also don't know what overseas support is like. However, when he joined last
November, Andy was one of the first six Sybase employees in the UK (and I bet
that Sybase set up here before anywhere else in Europe).

Steve

    I watched SYBASE try to setup a demo yesterday and their support
    is definitely in it's infancy.  Apparantly the aforementioned Andy
    was flown out here for a few week/months to be support till they
    got someone permanently.  The someone is actually another SYBASE
    UK employee who has migrated down under and has been here all of
    three weeks.  She has been with SYBASE since November last year
    so must have been another of the first 6 UK employees.
    
    Fastbuild has an Information Builder copyright message on the bottom
    of each screen.  I didn't see much of it so I can't comment on it's
    strengths and weaknesses but I do know it wouldn't work under VMS
    V4.7.  It worked ok under VMS V4.6.  The SYBASE server worked under
    both and they claim under V5.0 as well.  The demo didn't go ahead
    because of the fastbuild problem so they'll try again on Monday.
    
    -mark

    re: .8
    
    What was this about dynamic database restructuring?  One of my clients
    has Sybase and in the last planning session we were in, they assured
    me that you had to copy a whole table to change data types.  There
    was no dynamic re-structuring a` la RDB.  There are a number of
    other problems as well, but all of them relate around one thing:
    
    Ya gotta make copies of stuff to change it.
    
    The same problems exist for the triggers.  They must be manually
    reloaded into the database after changes.
    
    --------------------------------------------------------------------
    re the consistency remarks.  Has anyone got a really good explanation
    of what degree-3 consistency really means?
    --------------------------------------------------------------------
    re Sybase.  Their newest claim in the next while will be to run on
    SMP machines.  Coming soon to a 63XX near you (but not for another
    year or two or three...).
    
    						Neil

There have been several descriptions of Degree 3 in this conference.  I
can't say that any of them have been completely satisfactory.  It seems
that we have lots of trouble coming up with examples to convey the
problems with not using Degree 3!  I'm at home on vacation waiting for
someone show up at my door, so I'll try to explain it once again, though
I'll cut off the explanation if he shows up.

Degree 3 is also frequently called Repeatable Read because if you
repeatedly execute the same query within a transaction, you'll always
get the same answer (unless that transaction does something to change
the results).  A better way to summarize this is that the transaction is
isolated from any changes made to data it has already seen.  This can be
accomplished in a number of different ways.  For READ_ONLY transactions
this is accomplished by keeping multiple versions of the data around
(snapshots) and returning the same version each time the data is asked
for.  Thus, some other transaction can change the data but your
transaction always sees a consistent view of it.  For READ_WRITE
transactions this is handled by locking the records seen so that no one
else can see them.

The concept of Repeatable Read does not really justify the idea of
Degree 3 because few applications ever really repeat the read.  The
real concept that is being conveyed is that the state of the information
you read remains consistent throughout the transaction.  This applies
not only to the data in the records read, but ALSO to the implied
information contained within a query.  To illustrate this, take the
following pseudo-code fragment:

IF <rooms-available> > 0
THEN
    <accept-reservation>

Specifically, this take the case of a hotel taking reservations where
the reservations are NOT for a specific room, but just are held in
balance against the expectation that rooms are available (the case with
nearly all reservation systems, except when you do something like get a
seat assignment for a plane).  Now, with degree 3 the database system
MUST assure that <rooms-available> STAYs > 0 until the transaction
terminates.  Otherwise, it is possible that the IF condition could
succeed and then, before the reservation is stored, someone else could
reserve the last room!

With degree 2, if <rooms-available> is a count field in a single record
then this transaction probably works correctly.  However, if
<rooms-available> is computed by counting the rooms already booked and
subtracting from the rooms available, then a degree 2 transaction will
fail to work properly.  The reason is that degree 2 is not required to
prevent changes to previously read information and more importantly,
the invisible information.  What do I mean by this invisible
information?  Well, if you count the number of rooms already booked then
you have a piece of information that is not actually stored in the
database but is instead derived from it.  Degree 2 transactions do not
prevent this derived information from changing;  Degree 3 DOES!

This leads to the performance penalties associated with Degree 3.  In
order to prevent the derived information from changing Degree 3 must
often lock more than the records that are actually being looked at by
the application.  For example, if you read all of the reservations for
1/1/89-1/3/89, then a degree 3 transaction must make sure that NO NEW
reservation is stored within that date range until the transaction
completes.  Thus, it will usually lock the B-Tree node(s) containing
that date range so that no new records can be stored.  A degree 2
transaction, or anything inbetween, will at most lock the actual records
found during the search, but will not be able to prevent the new
insertions, or Phantoms.

In summary, using our example, a degree 2 transaction will generally
allow the hotel to unknowingly become overbooked while degree 3 will not.

There are many applications that depend on the information derived from
the database, as well as the data itself, remaining consistent
throughout the transaction.  Often, via extremely complicated and
contrived application programming these applications can be implemented
by degree 2 systems.  Degree 3 frees the application program from having to
worry about these problems.

My company arrived 5 minutes ago.  Ciao.

    Hal gave a good jyustification in .19.  Here's a more rigorous
    definition of *how* you know that a system implements Degree 3
    consistency.
    
    If a bunch of transactions all execute concurrently with Degree
    3 consistency, then the effect is the same as *some* serial execution
    of the transactions one at a time.  This can be achieved in a number
    of different ways.  Whenever a pair of transactions conflicts in
    some way, the system effectively picks one to *appear* to execute
    before the other.  With locking, the other transaction is made to
    wait.  With multi-versions, the first transaction reads an older
    copy.
    
    The guarantee that transactions behave as if they executed in some
    serial order is known as *serializability*.  This principle makes
    it easier for an application designer to ignore the concurrent activity
    that may be going on, because if his transaction behaves properly
    if run by itself, then it will never do anything wrong if run with
    Degree 3 consistency.
    
    If you care about *performance*, you can't completely ignore the
    concurrent activity, of course.  But at least you don't need to
    worry about your application making mistakes (such as overbooking).
    
    By the way, if a bunch of transactions run concurrently, some with
    Degree 2 consistency and some with Degree 3, then the Degree 3
    transactions will still behave as if they were run serially, one
    at a time.  This means that if you introduce some Degree 2 transactions
    to a working system, you only need to consider their concurrent
    actions on each other, and don't need to study the Degree 3
    transactions again.  That's one reason it would be nice for Rdb/VMS
    to support Degree 2 -- it doesn't open up too big a hole in the
    system's consistency.