Interestingly enough, MySQL was developed for a data warehousing project since the existing tools were too heavyweight (and expensive) for the project budget.
I taught a course at OSCON on MySQL Datawarehousing and it was *very* popular -- the Yahoo guys were there. And Monty. And a whole bunch of folks looking for fast database backends for reporting. It's been interesting to see the criticism over time for MySQL. It used to be "No transactions so it sucks" which was solved by InnoDB and BDB tables. There were all the "it's really slow" complaints which were knocked out of the park in 4.0 for many applications (the infamous eWeek comparison for example). There's always the referential integrity issue (you can acutually define foreign keys -- the engine simply doesn't enforce them... yet). And then the whole views/stored procs/triggers thing. And what else -- replication (works well in 4.0), unions (4.0), subqueries (working in 4.1 alpha). And of course the phpMyAdmin sucks (it does) which is partially answered by the new free cross-platform MySQLCC tool from MySQL AB. I can think of a much longer list of complaints about MySQL from years of use. varchar(255) is my biggest peeve, esp when converting from other dbs. Can't wait to see the criticism once 5.0 is out -- running out of things to miss :) By all means, please look at postgres if you need an "enterprise" db. Or MySAP.... at least until MySQL AB's finished integrating it. But MySQL has it's place. Datawarehousing (reporting) is one prime area. Places were speed is more important than amount of code (ie more code for referential integrity) developed. And as Jochem points out, it does a few weird things SQL-wise when you pass in bad values and strange situations -- that happens in most dbs, but MySQL seems to have (many) more quirks. Plenty of cool things. Customized table types PER TABLE (need a bunch of non-ACID lookup tables? MyISAM those puppies). The memory cache rocks! Runs on 64-bit AMD and Intel processors right now. DATE data types (try going back to the MS-SQL date difference code once you've worked with date intervals). Lots of internationalization options (even if it defaults to Swedish alphabet sorting in some versions... :) And most importantly, they've got the money to do things right (upwards of US$20M) which has let them hire all the key MySQL developers from the community (and writers like Paul DuBois). So you evaluate it -- does it work for your app or not? I now generally start projects either on MSDE/MS-SQL or MySQL for small-mid sized clients. The cost for Access (or MS-SQL) to MySQL is non-trivial so it's a good idea to make that decision early. Regards, John Paul Ashenfelter CTO/Transitionpoint [EMAIL PROTECTED] ----- Original Message ----- From: "Jochem van Dieten" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 5:43 PM Subject: Re: MS SQL Server vs. MySQL > Bryan Stevenson wrote: > > > > I'm not all that familiar with MySQL, but from what I hear it's not as good > > as MS SQL Server (which I use along with Oracle). > > "good" depends on the task. > > > > The MySQL.com website says that upcoming features for version 5 include: > > -views > > -stored procedures > > -triggers > > -sub-queries > > > > Now if it's missing all that then what is it....Access on steroids?? ;-) > > It is a fast data storage mechanism with a SQL like syntax. As > for SQL support and 'doing the right thing' I rate it lower as > Access, but it is fast and can handle concurrency better as Access. > > Very suited for read-only systems where data integrity or > relational features are not so important. (For instance, the US > Census Bureau uses MySQL to power their webservers. It is very > suited for that due to its speed and the price, but the actual > data the Census Bureau depends on is stored in Oracle and loaded > into the MySQL servers every night. Many other organizations use > MySQL like that.) > > IMHO it is most definitely not suited as a "no brains" upgrade > from Access. Due to the lack of features such as referential > integrity and views and the way in which some functionality > behaves totally different from Access (or any other database or > the SQL standard for that matter) you actually need to know quite > a bit about it. > > Jochem > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
