I''ve been evaluating frameworks, technologies, etc. for my company for a little while now. This is what I''m about to conclude for my report: 1. RoR is a good fit for new applications where we can define the DB schema. 2. PHP is a good fit where the DB schema already exists, or the "pieces" needed for the application exist all over the place. (ie: MS SQL Database for some info, Postgresql for more info, etc.) Is this a fair conclusion? Personally I like Rails alot, I just don''t see how it can be as strong as PHP with existing DB schemas (especially ones that cannot be modified). I know there are things a person can do to rig Rails to more than one DB and also to tie into existing legacy schemas but those are more a long the lines of hacks than anything else - they are not the "Rails" way. Am I off base here? -- Posted via http://www.ruby-forum.com/.
>From my experience, the benefits you get from using Ruby and Rails (yes,and, not ''on'') far outweigh the hassle of configuring ActiveRecord to use a legacy database. While Rails is the strongest in starting from scratch, it is very possible to make AR work for any schema, and once that is done, the rest of the application comes together as fast as any other Rails application. And it''s very easy to have multiple database connections in ActiveRecord: class PgSQLModel < ActiveRecord::Base connection ''my:pgsql:connection:string'' end class MySQLModel < ActiveRecord::Base connection ''my:mysql:connection'' end You then subclass either PgSQLModels or MySQLModel depending on what database the given table is in. Prototype out a part of the current website in Rails and see how well it transforms over. In the end, you can''t decide just on what someone says, you have to try it out and see if it works for you. Jason Wesley Lamb wrote:> I''ve been evaluating frameworks, technologies, etc. for my company for a > little while now. This is what I''m about to conclude for my report: > 1. RoR is a good fit for new applications where we can define the DB > schema. > 2. PHP is a good fit where the DB schema already exists, or the "pieces" > needed for the application exist all over the place. (ie: MS SQL > Database for some info, Postgresql for more info, etc.) > > Is this a fair conclusion? Personally I like Rails alot, I just don''t > see how it can be as strong as PHP with existing DB schemas (especially > ones that cannot be modified). I know there are things a person can do > to rig Rails to more than one DB and also to tie into existing legacy > schemas but those are more a long the lines of hacks than anything else > - they are not the "Rails" way. > > Am I off base here? > >
Wesley Lamb wrote:> I''ve been evaluating frameworks, technologies, etc. for my company for a > little while now. This is what I''m about to conclude for my report: > 1. RoR is a good fit for new applications where we can define the DB > schema. > 2. PHP is a good fit where the DB schema already exists, or the "pieces" > needed for the application exist all over the place. (ie: MS SQL > Database for some info, Postgresql for more info, etc.) > > Is this a fair conclusion? Personally I like Rails alot, I just don''t > see how it can be as strong as PHP with existing DB schemas (especially > ones that cannot be modified). I know there are things a person can do > to rig Rails to more than one DB and also to tie into existing legacy > schemas but those are more a long the lines of hacks than anything else > - they are not the "Rails" way. > > Am I off base here?I migrated my existing PHP application using migrations. It worked well and forced me to confront a number of underlying issues in my data model. In the end, I have a much more functional, extendable maintainable system. The PHP code was very bloated. Once the hard work was done on the model, the code for the application almost falls into place naturally. It seems like I wrote more lines of migration code than my entire app required. One really nice thing about this is you don''t have to argue with anyone about naming conventions in the DB -- just do it the RoR way. Another approach I heard about at the local Rubyists meetup was the use of Views in MySQL to give a RoR-friendly view into the legacy DB. I think it would be vastly more instructive and productive to use RoR in a re-engineering of a legacy system... particularly if it really has some life and value left in it. Greenfield development is less challenging. Steven -- Posted via http://www.ruby-forum.com/.
On 7/21/06, Wesley Lamb <wes.lamb@gmail.com> wrote:> I''ve been evaluating frameworks, technologies, etc. for my company for a > little while now. This is what I''m about to conclude for my report: > 1. RoR is a good fit for new applications where we can define the DB > schema. > 2. PHP is a good fit where the DB schema already exists, or the "pieces" > needed for the application exist all over the place. (ie: MS SQL > Database for some info, Postgresql for more info, etc.) > > Is this a fair conclusion? Personally I like Rails alot, I just don''t > see how it can be as strong as PHP with existing DB schemas (especially > ones that cannot be modified). I know there are things a person can do > to rig Rails to more than one DB and also to tie into existing legacy > schemas but those are more a long the lines of hacks than anything else > - they are not the "Rails" way. >What do you base this on?> Am I off base here?Yes.
Its boring to see often repeated discussion on Rails vs. PHP, or Struts vs. Rails, etc. There is already enough material out there on them, and any seriously interested person will search google and blogosphere before posting. Besides, this topic has been repeated so many times. Please don''t unnecessarily add to volume in this list. Thanks. -- Surendra Singhi http://ssinghi.kreeti.com, http://www.kreeti.com Read my blog at: http://cuttingtheredtape.blogspot.com/ ,---- | "All animals are equal, but some animals are more equal than others." | -- Orwell, Animal Farm, 1945 `----