Hello Sven!

On May 31, 2003 05:31, Sven K�hler wrote:
> Integrating SAPDB as a strorage-layer sounds like a good idea, but it
> also sounds like there will not be much of SAPDB left (which is a bad
> idea). Will there still be the feature- and config-richness that we are
> used to?
>
> SAPDB has some advantages over MySQL. For example you can communicate
> with the database using the DBMGUI, altough the Database isn't started -
> or not really started (admin-mode).
> So you can repair tables, set params etc....
> all without shutting down the whole DB-Server.
>
> >   Integration of SAP DB as a storage engine will not have us "restart" -
> >   instead it will be like the integration of InnoDB and BerkeleyDB as
> > storage engines. These were both cases where we provided our users with
> > additional functionality that they could easily start using due to the
> > shared parts of the management layer.
>
> InnoDB and BerkeleyDB are used as real storage engines by MySQL - i
> would call them a "file-format", but SAPDB is more like a concept for a
> whole DB. So which parts are you going to port, which not?
> 
> Perhaps you should think about porting the Network-Layer of SAPDB
> (called x-server) to be abled to have multiple DB-instances on one host
> with different kernel-versions each.
> This also includes the ability, to start/stop/config a DB while is isn't
> even started.

  I don't think that we know *exactly* what will happen. Initially, I believe
  that the plan is to make SAP DB understand the MySQL client-server protocol.
  This will allow for cooperation with little or no disruption to how SAP DB
  works now. As time passes, tighter integration will occur.

  Making the right choices will require that we receive guidance from the
  community. I suggest that we create a public mailing list specifically
  for users who wish to  participate the SAPDB/MySQL integration work.

  Since I cannot answer the above questions definitively, I will add them
  to the SAP DB/MySQL FAQ that will go up on mysql.com in a few days.

> >>> - Free from bugs
...
> The point is, that even Knuth can't write bug-free software, because he
> is "only human". (unfortunately these bugs haven't been found yet)

  I agree.[0] As I said, it is a *goal*. It is not a statement that we have no
  bugs - most sane developers will agree that bug-free is state achieved
  only when software is not running and has no users. ;)

...

> MySQL certainly has an image in the DB community. The ones searching for
> full-featured (enterprise) DB were always disappointed.

  I believe that we get negative press from people who do not understand that
  our greatest strength is ease-of-use and performance, rather than the 
  feature set we support.

  I agree that we do not have all the features of an enterprise database! At
  the same time, we excel in the areas that we are deployed in and continue to
  gain additional funtionality.

  This is why we are used by leading organizations like Yahoo!, the Wellcome
  Sanger Trust Institute, Ericsson, the US Census Bureau, etc.

  In an enterprise setting, we work very well as a compliment to more
  feature-rich databases and are good at replacing these same databases
  in areas where they have been over-deployed.

> >   If your concern is that we are not up to the task technically, we have
> > an excellent team - and this team will be working with the SAP DB team.
>
> Our doubt result from the image MySQL has - so you have to proove that
> you can stand that task, and that the result is a DB comparable to
> SAPDB. But after all you said, i fear that too many features/concepts
> are consired to be unimportant.
>
> >   In many ways you get the best of both worlds.
>
> hopefully

  I don't expect the SAP DB community to trust us without proof.  I do hope
  that we are given the chance to provide that proof though!

  Why do you feel that we consider features unimportant? Our focus in the last
  three years has become much broader. As we have gotten more and more users,
  they have taught us that they have different needs than we may have.

  Once we learned this, then we started implementing what they wanted. :)


  Thanks again for the feedback!

Cheers!
--zak
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to