Thanks for the response, Regarding... > Don't get me wrong, [subselects are] neat to have, > but I really don't mind waiting... > Are there other factors?
Yeah, we have SQL "dynamically" generated from "SQL Generator" code which is bombing out with queries having > 32 table joins and this will increase with planned product enhancements. Based on a large variety of user provided query values and user table column customizations, there are numerous permutations to much of the code created by the SQL Generator (patent pending) and there's a dependence on it over developing tons of hand written SQL code. It's thought to be easier to enhance the SQL Generator code to reduce table joins via some subselects than it is to introduce tons of hand written SQL code. Too many temp tables has been a problem in the past. Also, for existing and future enterprise level customers (non-hosted) there's a requirement to support the application on MS SQL Server, Oracle, and DB2 so writing ANSI SQL code is an absolute requirement. Development has its work cut out supporting multiple databases and MySQL's non-ANSI compliance is by far their BIGGEST complaint! What about hot backups with InnoDB? Is it a good 24X7 solution? We have > 20 servers and if we have to replicate everything it could get expensive and require a lot of disk. D. B. --- Michael Bacarella <[EMAIL PROTECTED]> wrote: > > 1) ACID compliant transaction support. There is > > concern as to whether InnoDB is ready for prime > time, > > especially as regards backups and our 24X7 needs. > Our > > databases can grow very rapidly and we can't > afford to > > bounce the database just to add datafiles as is > > currently required for InnoDB. > > If you need to add new datafiles, start them small > and flag them > autoextend. Should take InnoDB no time at all to > initialize them. > Or flag them autoextend to begin with. > > We tax Innobase -very- heavily and it has proven to > be > both fast (much faster than MyISAM for our purposes) > and > *extremely* reliable. > > The support we've received has also been > outstanding. > See the list archives, even people with Oracle > support > contracts claim to receive far better service from > this > list. > > > 2) Excessive code to work around non-support for > > subselects. While subselects are scheduled for > stable > > release in mid 2003, we can't wait that long and, > > based on past delivery of MySQL promised features, > the > > current view is that subselects won't really be > tested > > and supported (in stable production) until mid > 2004. > > I hate to say it, but this sounds more like > egotistical > bellyaching than a severe development crisis. > Alternatives > to subselects are so easy to string together that I > seriously > question the motives or abilities of people who > CANNOT survive > without them. Don't get me wrong, they're neat to > have, but I > really don't mind waiting, given how fast, simple, > and well > supported MySQL is. > > > Is anyone willing and able to help me provide some > > defense for MySQL on this? > > Try MySQL Myths Debunked: > > http://m.bacarella.com/projects/mysqlmyths/ > > > History: > > We have experienced dramatic growth and our > software > > is somewhat mature being maintained and enhanced > by > > over 2 dozen fulltime developers and 7 sysadmins. > > Generally there is one database for each customer > and > > each customer may have 10,000's of endusers who > access > > our hosted databases. Currently we host our web > > application to about 1000 customers/databases on > > several large multiprocessor database servers with > a > > coule EMC disk farms. We have multiple data > centers in > > multiple locations. We have many database.tables > with > > multi-million rows and a lot of concurrent enduser > > query access. Larger customers have occasionally > > sustained peak loads of 200 queries per second and > on > > a few rare occasions we have neared 1000 queries > per > > second for a single database for relatively brief > > periods. There are a significant number of > > inserts/updates that have created table locking > > problems and future software releases will be even > > more transaction intensive. > > > > Management thinks we have outgrown MySQL and need > a > > "better" database. I need some MySQL ammunition to > > defend against changing databases. HELP... > > Migrating databases isn't something to undertake > lightly. > > Make sure some egomaniac isn't pushing for it just > because > of prejudices. Migrating a system such as this > simply because > of lack of subselects sounds insane (how have you > coped > up until now?) > > Are there other factors? > > -- > Michael Bacarella | Netgraft Corp > | 545 Eighth Ave #401 > Systems Analysis | New York, NY 10018 > Technical Support | 212 946-1038 | 917 670-6982 > Managed Services | http://netgraft.com/ > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
