Wesley L. 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:
- RoR is a good fit for new applications where we can define the DB
- 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.