Hi Sven, Thanks for the feedback!
On May 30, 2003 19:45, Sven K�hler wrote: > I don't comment the licensing situation, as long as i don't really know > if using GPLed software (e.g. the JDBC driver) influences my work, but > it will influence the work of others, that want to redistribute the > currently LGPLed components as part of their software - as far es i know. We are working on the licensing issues. We do not want to punish the SAP DB community as a side effect of this partnership. We will need some time to sort these issues out though, and may not be able to make everyone happy. > > We want the MySQL server to be: > > - The best and the most used database in the world > > It is surely one of the most used databases, and MySQL was evolving into > a database with more reasonable features with each version, so why do > you do some kind of "restart" by using SAP DB? MySQL is a combination of a management layer and various storage engines. The management layer provides a uniform interface to the various storage engines, while the storage engines provide the bulk of the actual functionality. 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. It will give a large community of users easy access to SAP DB and will vastly increase the rate of adoption. > What about the "best database in the world" ? > To my knowledge, that concepts behind the O in ORDBMS are "state of the > art" and think that these are worth it to be included in a new > database-product. These is a goal. We have not reached it yet. :) Perhaps this involves ORDBMS, perhaps not. > > - Continuously improved while remaining fast and safe > > "safe" might conflict with "fast". Often MySQL users asked, why SAPDB is > so slow on INSERTs - the reason is clear, because it does it's job well, > and flushes the data to disk on every COMMIT. This is one reason that we support multiple storage engines. Some engines emphasis some features over other features. We still want to focus on having a database that is fast and safe. Also, this perception may stem from the users running in auto-commit mode. This would apply the overhead of a transaction to each INSERT. Users would see a similar pattern using the InnoDB or BerkeleyDB storage engine in MySQL if they are in auto-commit mode, rather than grouping INSERTs within a transaction. Regarding the safety of transactions, the InnoDB storage engine is a transactional, multi-versioned storage engine that also flushes to disk on every commit. > > - Fun to use and improve > > ??? Of course! Unhappy coders produce crappy code. :) > > - Free from bugs > > Are you kidding? No Software is Bug Free (except for TeX ;-) ). Again, another goal. Focusing on being mostly bug-free would be pretty lame! :) Of course, we would never aspire to be as exalted as any program written by Donald Knuth! :) > > In the last few days, valid concerns have been raised about the possible > > negative effects of the agreement between SAP and MySQL. Over the next > > few weeks, we will be working on addressing these concerns. > > Imagine, you would want to buy a car. This car is build by a company, > that is knows for buidling good cars, and now you hear, that this car > won't be available again, but there is a successor which is build by a > company that is known for building much simpler cars. > > Would you buy that new car? I guess not. That is only part of the picture. SAP's core business is ERP systems. Our core business is databases. We focus only on our databases and database related issues - we are better organized to provide support for database users. 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. In many ways you get the best of both worlds. Of course, a possible downside are the licensing issues. > > Our belief is that you, the SAP DB community, and we, MySQL AB, together > > can grow the SAP DB market from the foundations laid by SAP and its > > predecessors. > > All we hope - or at least i do - is that the "MySQL SAPDB" and the > successor of SAPDB will be as good or even better than SAPDB it is now. > I still don't know, if this new product will be build on base of the > SAPDB sources, or if it will be a completly new product (restarting from > scratch or with the current MySQL sources.) In the short term, SAP DB will be a storage engine. Over the long term, we will work with SAP to integrate the SAP functionality into another MySQL storage engine. This migration will make the code easier to comprehend and modify - being based on a more standard set of tools in use by the free/open source community. > I like many things about the current SAPDB > - the installer > - installing many kernel-versions on one machine (some host/port etc.) > - support for UNICODE (although some features are missing) > - a management-application like DBMGUI > - a query-tool like SQLStudio > > All tools should be cross-platform UNIX/Windows. Good! We should discuss this more as development moves ahead. Cheers! -- Zak Greant MySQL AB Community Advocate _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
