First of all, thank you Zak to answer the questions and give as much information to the community about the cooperations as you can.
The name of database: I think it's understandable that MySQL AB want to give it's name to the database. IMO it's not an important question, if SAP AG accept it, we must accept also.
Comments on some previous messages:
Zak Greant: >> The potential for increasing the usage levels of SAP DB is quite >> tremendous.
Christian Ullrich's answer:
> We don't like the database just because it's called "SAP DB".
> We like it because it is good. Very good, indeed.
SAP DB is the best database that is available with GPL licence. (I don't have experiences with Oracle and DB2, but I think we may say SAP is as good as Oracle or DB2)
It is extremely reliable, have a very mature concept and good performance, it's a heavyweight database.
Christian Ullrich: >>That's not the fault of the software, but of SAP, who haven't done >>anything to attract attention to the software.
Zak's answer:
> I don't necessarily agree. MySQL was one of the first free/open source
> databases to meet the needs of a large segment of the market. SAP DB
> was simply introduced at a time when gaining mindshare was difficult.
>
> Additionally, I believe that our ease-of-use has a lot to with our massive
> levels of adoption.
I think Christian is right. IMO this cooperation will be very good for SAP AG and MySQL AG, beacuse SAP get a big community and a part of this community will use and develop the database. MySQL get the best database of the open-source world.
Sven K�hler: >>>We listen ... oops ... read your words with very much interest, and you >>>said that SAPDB would be added to the list of supported storage engines, >>>which would mean that very many features are thrown away.
Zak's answer:
> Aha! I was just chatting on with a few of the developers who said, "Zak, it
> won't be a storage engine. It will be *interoperable*. Now go take a bullet
> for the team and explain that you were wrong."
Does it mean that you will make SAP DB and MySQL to be interoperable, and SAP DB will be a separate system with all of the advantages of it?
I think it will be wise/the right decision and on long term you should build the "next generation database" over the SAP DB concept and codebase.
Sven K�hler: > You cannot integrate SAPDB into MySQL without loosing all those features > that make SAPDB this beautifull. > > I have to repeat my self: > - _learn_ from SAPDB > - don't even think of integrating SAPDB into MySQL > - build a new product with all good concepts of both products I think he's right.
To SAP DB users and funs:
We should make a list of the loved and important features of SAP DB, that MySQL AG may take into consideration and we can discuss the problematic questions with them.
List, that I collected from your letters and also contains my thougths:
Sven K�hler:
- 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
- communication abstraction layer (e.g. local communication or sockets like SAPDB's x-server and the API it uses)
- each DB has it's own independant threaded kernel-process with its own paramaters (e.g. if one kernel crashes, the others aren't afftected at all)
- user scheme like all other enterprise DBs (each user has its own tables etc.)
- two online modes a DB (e.g. admin mode, warm mode)
- storage abstracting layer (e.g. files, raw devices)
- ANSI SQL Syntax
- foreign keys
- transactions
- smarter limitations (e.g. postgresql has a row-limit of 1.6TB)
- table inheritance (with renaming, ORDBMS)
- Unicode support (i think UTF-8 is crap for sorting and other stuff, should be UCS2 perhaps)
- correct sorting of Unicode chars (perhaps user-definable sorting-maps)
- all tools should be cross-platform UNIX/Windows.
Thomas Cataldo: -For exemple with sapdb you can tune your memory settings with a database granularity, for example I can have a test database with 64MB and 1 CPU allocated and a production database with 1GB allocated and 4CPU allocated. I think Cataldo thought of paramter settings.
Edson Carlos Ericksson Richter: -don't change any existing code related to SQL syntax (excetp additions: they will be welcome) I think it's right in short term.
My thoughts: -backup and recovery system -online backup -param settings (resource management, online db size change, etc.) -(foreign) constraints -user concept -procedures, triggers
Feature wishlist:
-UTF-8 (later ucs4 too) handling beside the existing unicode handling in db and db funtions (e.g. it's very useful in web service enviroment)
-locale handling to string and date/time functions, and char fields (it can be useful when ordering by char field)
(e.g. you can use ibm's icu, if the licence is acceptable to MySQL AG)
-more powerful sql language (something similar to Oracle's PL/SQL)
Finally, but not last, I must tell you that I'm very confident of this cooperation.
Best regards, Kriszti�n IVANCS�
_______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
