Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!postgres!larry
From: larry@postgres.uucp (Larry Rowe)
Newsgroups: comp.databases
Subject: Recent discussions... (*long* controversial message)
Message-ID: <16753@pasteur.Berkeley.EDU>
Date: 1 Sep 89 07:17:37 GMT
Sender: news@pasteur.Berkeley.EDU
Reply-To: larry@postgres.UUCP (Larry Rowe)
Organization: Postgres Research Group, UC Berkeley
Lines: 198
References:
Keywords:

as usual, i haven't been reading this list for a while.  so, after plowing
through 200+ messages i have a few comments.

1. bundled rdbms's
someone made the comment that the issue of embedded dbms was really a
bundling issue.  i think that comment hits the mark.  ansi compatible sql
dbms engines will become a commodity.  commodity products are sold by
vendors that are the low cost producers.  3rd party companies cannot compete
with the hardware vendors for low cost to produce and 
sell because the hardware vendors
have high margins built into the product they are selling -- a system
including hardware and software. ibm has bundled an rdbms with OS/2 and dec
is bundling rdb with vms and ultrix.  (rdb/ultrix is actually rtingres
that was licensed by dec.  rti isn't naive.  dec will replace the rti
product with an internally generated product asap.  they are rumored to
be working on one now.  but, they had time to market problem.  exact
same story holds for risc processors.)  they are doing it for two reasons.
first, they want to use the rdbms in their other products (e.g., to store
compiler symbol tables for object modules that can be accessed at run-time
by debuggers and to store system management information such as network 
configurations, user authorizations, etc.).

the rdbms vendors have slowly converged to products with roughly the same
functionality and performance.  another couple of releases from all the
vendors and the ansi sql engines will be indistinguishable.

someone else jokingly commented that the hardware vendors are bundling
to control customer accounts.  that too hit the mark.  ibm made 
many, many dollars selling ims and hardware to run it to companies doing
large *production* applications (think banks, railroads, 
large manufacturers, etc.) that spend $10M - >$100M on software and 
hardware per year.  ibm controlled the accounts because they sold the
hardware and they sold the software that ran *the very most important
applications*.  ibm and other large computer vendors will do the same in
the future to try to stave off the threat of hardware/os independence.

bottom line: 3rd party dbms companies had better have a strategy to produce
products that will replace the sales dollars they make on their sql
engine today.  my guess is that they have something less than 5 years to
do it.

here's what some companies are doing:

ORACLE: run everywhere and sell applications.  by running everywhere they'll
find some markets not dominated by the hardware vendors.  users want 
applications not dbms, so sell it to them.  of course, you bundle the dbms
in your application and move your profit from the dbms sale to the
application sale.

RTI: distributed dbms, integrate heterogeneous dbms's, and sell 1st rate
development tools.  distributed dbms is new technology.  3rd parties will
lead the hardware vendors.  hetergeneous dbms's cross vendor lines since most 
companies have products from many different hardware vendors.  3rd parties
can win this business for a while too. 1st rate development tools solve 
problems of building applications.  if you can't buy the application you 
want, get the best tools to build it.  for some reason i can't determine,
neither dec nor ibm has produced competitive 4gl's.  it's probably because
the programming tools groups in the companies are database naive.  they 
just don't understand what customers are doing with the dbms.  (note: there are
*many*, *many* tools vendors.  there's probably a shakeout coming in this
market in the next 5-10 years.)

INFORMIX: unix application business.  wingz looks like a winner in the mac
marketplace.  watch for it to appear on other platforms (e.g., unix(!)
and pc's).  then, scrounge for info as to when revenue from wingz is greater
than for rdbms products.  i wouldn't be surprised if it happened within
2-3 years.

SYBASE:  unkown.  but, first they have to catch up with oracle and rti.
i think sybase did $25M this year.  oracle did approximately $600M.  rti
did $130M.  the rdbms market seems to be growing at somewhere around
40% per year.  i don't see a breakout strategy for sybase that will cause
them to win a significant percentage of the rdbms business.  they'll
obviously survive, but are they destined to always be in 3rd place.  they
had a chance with SQL server, but that seems to be a receding opportunity.

UNIFY: application development tools. they've already abandoned the dbms
business.

ASHTON-TATE:  unkown.  recent decomit to sql and network products on dos
and their weak financial results suggests they are in for a tough time.
640K pc/dos machines are not a growth market.
AT hasn't shown any ability to produce a competitive product in
another market (remember "dbase for the mac"?).  note: i think AT did 
roughly $250M this year.  they might be a takeover candidate for a 
company that wanted to fire 75% of the people and sell dbase as a 
cash-cow product.  (do i hear computer associates knocking on the door?)

SHAREBASE: unkown.  revenues this year were approximately $40M.  sybase
will probably pass them this year.  i haven't followed their financial
results closely for the past couple of years, but i don't think they've
done very well.  i think they hit higher revenues in previous years.
rumors are that technical people are abandoning ship.  they may not last 
much longer.

2. OO -vs- R dbms wars
i found the discussion interesting.  however, it seems to me that the real
issue is "ease of expression" -vs- "performance".  it is *absolutely* clear
that oodbms's solve a problem for people building CAx products today.  most
CAx companies build their own dbms's (read 10-20 developers).  if they
could buy a product rather than build their own they would be *much* better
off.  all CAx company managers know this and they're looking for a product.
i'm sure one or two of the "O" companies (ontologic, object design,
objectivity, and object sciences) will succeed at selling into this market.
the OO-C++'s that they are producing will provide good performance and
ease of expression for those applications.

at the same time, i'm sure that all 3rd party rdbms vendors will put OO
constructs into their data models (inheritance, path expressions like
"dept.mgr.salary" that eliminate explicit joins, methods into the query
language, object identity, etc.).  the advantages for data modelling are too
substantial to ignore.  query language you ask?  sql of course.  the market
announced load and clear that's what they want.  the "O" companies will hear
the same market.  they'll have to provide an sql interface (both embedded
and ad hoc query) or they'll be confined to a nitch market.  too many people
are building too many applications and investing in too much training based on 
sql to walk away from it.  unless the "O" companies can show a >10X improvement
in productivity, i doubt that people will be willing to switch.
personally, i doubt that you can do it with just an OO programming language.

of course, the "R" companies (rti, oracle (formerly relational software),
informix (formerly relational database, inc?), etc.) will create OO versions
of their programming languages too.  OO-3GL's and OO-4GL's.  and, i'm sure they
will get forced to do C++ embeddings sometime too.  now, can they create
seemless integrations.  depends on how hard they want to work at it.  
personally, i think they can do it.  simple thought.  every implementation
tactic used by "O" companies can be put into "R" company product.  the same
primitives called by the language run-time system to the data storage system
of the OO-C++ products can be implemented within the relational dbms.  not on
top of, within.  several people mentioned that "R" products are putting in
db procedures to win tp1 benchmarks.  currently those procedures are coded
in a 3GL or 4GL.  but, they could just as easily call routines coded in
the dbms implementation language (C) and they could access *any* internal 
interfaces in the backend.  

the difference the OO-C++ products will have is the effort they put into the
programming language runtime environment (object caching, smart pointer
swizzling, locking, etc.).  (btw, dan and jack.  are you planning on
supporting ad hoc queries in C++ that touch objects in the object cache and
in the backend?  how many lines of code are you going to write in your 
distributed query optimizer and executer? i'll bet you'll finesse this for
now because it isn't crucial to your target market.  it will be if you want
to get into the bigger MIS and end-user market.)  the "R" companies could write
this same code but they probably won't unless they believe it is a big
enough market to go after.  and that's where the uncertainty is.  the "O"
companies think their market is potentially huge.  the "R" companies aren't
convinced that it is as large as they think.  this is a standard dilemma
when technology changes.  sometimes big companies win (ibm waited until
apple proved there was a market for pc's, then they waded in and took over
the market) and sometimes they lose (the network dbms vendors didn't believe
that rdbms's mattered and they were destroyed by the "R" companies).
what will happen in this case?  only time will tell.  

i wish the "O" companies well.  it's great fun to be in a start-up 
during product development and early missionary work.  
one thing though.  relational products didn't really take off until ibm 
blessed the technology by announcing db2.  i worry about the oodbms 
technology because ibm doesn't have any internal project building prototype 
products that they can pick up and productize. they have starburst, but it
is an extended relational product along the lines of postgres rather than
a true OODBMS.  that suggests the adoption 
cycle could be long.  the investment community only gives companies about 5 
years to make it.  after that they have a *very* hard time raising money.  
the AI companies ran into this problem.
i'm frankly surprised that ontologic is still able to raise investment 
money given that they've built two products that failed.  i suppose  it is
because the new "O" companies have shown that there's money to be made and
ontologic has more experience than the new companies.  

3. Using relational dbms's
someone from servio-logic commented that relational db designs normalized
their data and that forced applications to do joins which were too slow.
in fact, that is the theory, but not the practice.  ted codd wrote a paper
in the early 70's that said you must denormalize your design to meet the
performance requirements of your application.  every smart relational
application builder does this.  unfortunately, there are a lot of
"doorknobs" writing applications that won't violate a theoretical rule.
they fail at writing applications which leads to two comments:
	1) people claim that rdbms's don't perform as well as product X and 
	2) there's money to be made as an application consultant.

in fact, rti stores almost all application descriptions in the rdbms (e.g.,
form definitions, report definitions, and most of the definition of an abf
application -- in fact the only thing not stored in the dbms is the abf
operation code which was my decision and one of the biggest mistakes we 
made because it complicated all the dbms utilities -- copy-database,
unload-database, etc. had to do something special for abf code).  these
are complex objects with shared subobjects.  the performance of the
interface tools operating on the descriptions in the dbms is evidently 
acceptable since users haven't abandoned the tools.  the trick is to 
precompute a main memory representation of the complex object and store
that in the dbms along with the normalized version.  i developed this idea
about 7 years ago at Berkeley.  we expanded on it in postgres and the
picasso interface toolkit that i've been working on for the past 3 years.

------
so enough for now...let the responses begin!
	larry