>when they hit this kind of problem >they assume it's a limitation of the kind of tools they are using Exactly, mostly its a suboptimal implementation of these technologies
Our core business is reporting with complex risk modeling, we do intensive risk calculations on raw data using complex joins on millions of rows of data using page long SQL queries at time, and they do just fine on Postgres (milliseconds to a few seconds at worst). Occasionally we use some C functions when speed is an issue, but SQL joins are *hardley a bottleneck. Peter ----- Original Message ----- From: "Chris Wareham" <cware...@visitlondon.com> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Friday, 23 January, 2009 12:45:58 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: PostgreSQL vs MySQL with Tomcat Jonathan Mast wrote: > Perhaps the discussion should move back towards how Tomcat interacts with > databases. > It would be more on topic, but a well architected web application will have a data access layer that is not dependent on the Servlet API, both for testability and reusability. While a data source may be configured in Tomcat, the correct use of dependency injection would mean that the data access layer shouldn't be concerned where the data source comes from. To reiterate, database interaction is an architectural issue, not a web container one. > This thread seems to be damning MySQL for not having super advanced > features, some of which should perhaps not even be in the purview of the > database layer, but more appropriately belong at the application layer (ie. > Tomcat). > No, many people damn MySQL for it's lack of standards conformance and idiosyncracies that make it harder to maintain data integrity. I am particularly wary of MySQL because of the way missing features have been disingenuously described as unnecessary, and broken features as the MySQL developers knowing better than everyone else. > For example, I rewrote a report generator for my company. The existing > generator, a PHP + MySQL setup, was insanely slow and difficult to maintain > being that it consisted of 1 php page containing hundreds of lines of code. > I rewrote it in jsp + POJO and the new version runs much faster, because it > doesn't have a single query with a JOIN clause in it. The old generator had > super complex queries that took forever to run and placed an enormous amount > of load on the database server. I achieved that same result of a JOIN by > pushing that functionality up to the Java layer. > > Sure we can argue about which DBMS has the fastest JOINs but nonetheless it > remains that JOIN queries will always be computationally expensive compared > to single table queries. > > Well thats my 2 cents :) > By it's very definition (see Codd or Date), an RDBMS should be capable of performing joins with good performance. MySQL often struggles to do so thanks to the poor optimiser, so you had to implement what should be core functionality of an RDBMS in your application layer. Great. Did you try explaining those queries to find out if reordering the joins would give the performance you were looking for? Or is MySQL the only database you are familiar with? This is the problem with much of the LAMP crowd - they've never tried anything else, so when they hit this kind of problem they assume it's a limitation of the kind of tools they are using, not of the specific tools themselves. Chris -- Chris Wareham Senior Software Engineer Visit London Ltd 6th floor, 2 More London Riverside, London SE1 2RR Tel: +44 (0)20 7234 5848 Fax: +44 (0)20 7234 5753 www.visitlondon.com 'Visit London Limited' is registered in England under No.761149; Registered Office: Visit London, 2 More London Riverside, London SE1 2RR. Visit London is the official visitor organisation for London. Visit London is partly funded by Partnership, the Mayor's London Development Agency and London Councils. The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you have received it in error, please notify the sender immediately and then delete the message. If you are not the intended recipient, you must not use, disclose, copy or distribute this email. The views expressed in this e-mail are those of the individual and not of Visit London. We reserve the right to read and monitor any email or attachment entering or leaving our systems without prior notice. Please don't print this e-mail unless you really need to. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
