In this presentation, I wish to challenge some orthodoxy within and around Rails. My main concern is that is only one good reason to use MySQL, and that reason should not appeal to most Rails developers. I will be contrasting Rails with PostgreSQL which is the most obvious alternative for this audience. The position that Rails holds as the default open source database is certainly not idiosyncratic to the Rails community. But that position is supported by DHH’s support for MySQL, along with his distaste for stored procedures and the like. My second proposition tonight is that there certainly are valid uses for code in your database, and I hope to end by raising the question of how it affects your code if you decide to make your Rails database smart for general discussion.
1. MySQL, PostgreSQL and Rails <ul><li>A polemic </li></ul>
19. http://www.kitebird.com/articles/ruby-mysql.html Guess what license?
20. The PostgreSQL license PostgreSQL Data Base Management System Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group Portions Copyright (c) 1994-1996 Regents of the University of California Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
22. On clever databases
23. — DHH We took a pretty radical stand: Stored procedures and all things that make your database clever are evil
24. Application database
25. Integration database
26. Integration database ✔
27. Complex processes
28. Recursive structures (etc)
29. Smart databases & Rails <ul><li>Maintain with migrations </li></ul><ul><li>..? </li></ul>