Comments on: Database Read/Write Splitting in Frameworks/ORMs http://eric.lubow.org/2010/databases/mysql/database-readwrite-splitting-in-frameworksorms/ Thoughts, musings, and other idealistic (sometimes useful) systems and development hoopla. Thu, 01 Sep 2011 07:34:48 +0000 hourly 1 http://wordpress.org/?v=3.1.4 By: Eric Lubow http://eric.lubow.org/2010/databases/mysql/database-readwrite-splitting-in-frameworksorms/comment-page-1/#comment-25837 Eric Lubow Wed, 03 Mar 2010 04:47:24 +0000 http://eric.lubow.org/?p=563#comment-25837 I agree with your assessment of the goal of frameworks. But if you reach the issue of scaling, is it really worth refactoring the entire code base to scale out your database system? And if a framework is solving 80% of your problems, does that mean that when your ready to scale out that another problem should be created as to how (on the database level)?<br><br>The point I am aiming to make is that by baking this ability into the core code base of a framework and making it available to use when necessary (or desired) you are giving the developer the ability to scale more easily. And I believe giving this ability in advance is less dangerous than having someone try to hack it in later. It also provides a consistent way of achieving this goal for everyone who uses a framework/ORM to follow so there aren't people consistently reinventing the wheel. I agree with your assessment of the goal of frameworks. But if you reach the issue of scaling, is it really worth refactoring the entire code base to scale out your database system? And if a framework is solving 80% of your problems, does that mean that when your ready to scale out that another problem should be created as to how (on the database level)?

The point I am aiming to make is that by baking this ability into the core code base of a framework and making it available to use when necessary (or desired) you are giving the developer the ability to scale more easily. And I believe giving this ability in advance is less dangerous than having someone try to hack it in later. It also provides a consistent way of achieving this goal for everyone who uses a framework/ORM to follow so there aren't people consistently reinventing the wheel.

]]> By: matticakes http://eric.lubow.org/2010/databases/mysql/database-readwrite-splitting-in-frameworksorms/comment-page-1/#comment-25836 matticakes Wed, 03 Mar 2010 03:14:57 +0000 http://eric.lubow.org/?p=563#comment-25836 While I see the point you're raising I think it's interesting to keep in mind the ol' 80/20 rule. A web framework is trying to solve 80% of the problems for you.<br><br>They get you *most* of the way there, quickly. When you're hitting scalability issues it might be time to break out of the confines of an ORM anyway, whether or not you've encountered this particular issue. While I see the point you're raising I think it's interesting to keep in mind the ol' 80/20 rule. A web framework is trying to solve 80% of the problems for you.

They get you *most* of the way there, quickly. When you're hitting scalability issues it might be time to break out of the confines of an ORM anyway, whether or not you've encountered this particular issue.

]]>