On Sat, 2003-05-31 at 07:56, Zak Greant wrote: > 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.
Well the sapdb case is pretty different : sapdb front-end has more features than the mysql one (subqueries, oracle syntax, etc) and relegating sapdb to a storage engine is a big feature regression from a sapdb point of view. Also consider another point : mysql database concept is just a schema for sap. With sapdb every database instance is a separate set of process, with different set of users. 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. MySQL is a mono instance database, so every "database" runs in the same address space and that is a big concern for me. InnoDB is pretty cool, but the mysql architecture enforces the one machine/one database model. The most disturbing thing for me with mysql is the 'mysql' database, and storing the users in a global area instead of a per instance area. Of course I'm far from being a mysql expert so if I can have address space/process separation between database instances and storage separation between all the database, feel free to correct me. Thomas. _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
