Rails: Good for everything?

My department is in a battle right now. We have some very por PHP
people and very pro Rails people. The php guys make a good argument
that Rails is good for new applications where we dictate the DB schema.
PHP shines where we go into an existing application, or a new one where
multiple databases or possibly legacy systems are involved. The PHP
guys basically say Rails is good for Web 2.0 type apps whereas a PHP can
do it all - including the Web 2.0 stuff (ie: CakePHP, Symfony, etc.)

The Rails guys claim that they too can do legacy system support or
mutiple databases but I’ve checked into this and its not as clean as the
PHP way of doing it. Rails certainly appears to me to want 1 db to
point at.

I can see Rails being easier to maintain and hire programmers for (PHP
talent is all around). I cannot see as many Railers out there yet.

Advice?

Accessing more than one database is easy enough - I just created a base
model that uses a different database, then derive additional table
models from it. Prag Dave had a tutorial about it, but I can’t seem to
find it.

Joe

Joe wrote:

Accessing more than one database is easy enough - I just created a base
model that uses a different database, then derive additional table

…and I’ll just pop in with an example. We have a portal like
application that pulls data from numerous databases. The
usernames/passwords are in their own database so this can be shared
throughout the portal apps easily. This tends to get difficult with
Rails because anytime I see something to do with multiple database
access in Rails I quickly see the term “hack” soon afterward.

Here’s what I have in /app/models:

class ImportBase < ActiveRecord::Base
establish_connection(
:database=>$import_database,
:adapter=>‘postgresql’,
:username=>‘joe’,
:password=>‘12345’)
end

class ImportItem < ImportBase
set_table_name ‘es_items’
end

$import_database is defined in a lib script I use for importing - could
likely put it in environment.rb or elsewhere. Then I just use the models
like:

import_item = ImportItem.find_by_title(title)

Easy.

Joe

On 7/12/06, Bob Y. [email protected] wrote:

My department is in a battle right now. We have some very por PHP
people and very pro Rails people. …

Sorry this is totally a waste of bandidth but it seems like a very
funny freudian slip right there.

Can you go with both? Each is a tool that is suited well for different
things. If PHP works the best then honestly use PHP, but if rails is a
better fit go for that. It doesn’t seem like they’re saying that you
should never use rails just that there are some situations where it
might be more advantageous to use PHP.

Let the PHP guys do something in PHP, and let the Rails guys do
something in Rails.

Could this be an option?

On 7/12/06, Bob Y. [email protected] wrote:

My department is in a battle right now. We have some very por PHP
people and very pro Rails people. The php guys make a good argument
that Rails is good for new applications where we dictate the DB schema.

That’s a red herring. It’s fairly easy to use legacy schema’s.

PHP shines where we go into an existing application, or a new one where
multiple databases or possibly legacy systems are involved. The PHP
guys basically say Rails is good for Web 2.0 type apps whereas a PHP can
do it all - including the Web 2.0 stuff (ie: CakePHP, Symfony, etc.)

Php makes a very poor general purpose programming language. Rails is
a web platform written on top of ruby, a very good general purpose
programming language. You really aren’t even comparing apples to
apples here.

The Rails guys claim that they too can do legacy system support or
mutiple databases but I’ve checked into this and its not as clean as the
PHP way of doing it. Rails certainly appears to me to want 1 db to
point at.

If you do want to use multiple databases, there are several ways to
do so, and they are much cleaner than how you would do it in php.
Defining a db connection per model, for example. How much cleaner do
you want it?

Bob Y. wrote:

My department is in a battle right now. We have some very por PHP
people and very pro Rails people. The php guys make a good argument

Why one or the other? Use the appropriate tool for the job or your
wasting money and time.

Eric

Bob Y. wrote:

PHP way of doing it. Rails certainly appears to me to want 1 db to
point at.

We have multiple databases, in fact an Oracle and a Postgresql database,
in the
same application.

The trick here is to have each ActiveRecord subclass call
self.establish_connection in the class definition itself and pass it the
connection name as defined in the database.yml file.

You do need to be careful in that different models to the same database
do not
open their own connection, otherwise you’ll see odd breakage with
transactions
not working correctly.

In our case, the Oracle models are the default and the Postgresql models
need
special care:

class Post < ActiveRecord::Base

This table is in a Postgresql database. All models that use the

Postgresql database must use the same connection, otherwise when

more than one model works with the database in a transaction, the

models that did not initiate the transaction will not be working

inside the transaction and will be using their own connection.

Save the connection in a special location so that all models can

share it.

if self.active_connections.has_key?(:PostgresqlConnection)
self.connection = self.active_connections[:PostgresqlConnection]
else
self.establish_connection(‘postgresql-accessory-db-’ +
ENV[‘RAILS_ENV’].split(’-’).last)
self.active_connections[:PostgresqlConnection] = self.connection
end
end

Regards,
Blair


Blair Z., Ph.D.
[email protected]
Subversion training, consulting and support
http://www.orcaware.com/svn/

David N. Welton wrote:

Unless the tools are so far apart in their target, the economics of
software (or at least my understanding thereof) suggest that you’re
likely to reap some benefits by not having too many different tools
floating around.

Possibly. I think it greatly depends on your business. If you are doing
all your development around one central concept and you must do a lot of
custom software when working on that concept it makes sense to stick
with one tool so you only have to develop that custom software once
(perhaps but even then I would just argue that you ensure your custom
software is easily available from other tools).

On the other hand, in just about every other case there is probably
already a tool to handle a job for just about every task you want to do.
If you can find that tool and use it you will be much better off than
trying to develop and maintain what you need.

For example I recently was developing an web application that had to
interface with dates generated by Excel. Excel dates are something funky
(which I won’t go into here). If I am developing in PHP or Ruby I would
have to create my own code to transform the Excel date into a reasonable
representation. I have never done this because there is a perfectly good
module developed and maintained by someone else on CPAN
(http://search.cpan.org/~drolsky/DateTime-Format-Excel-0.2901/). Instead
of rolling my own I use another tool that is better for the job by
escaping out to the shell and having perl do the dirty work for me.
Every tool has strengths and weaknesses. If you stick with one tool you
will be constantly spending your time filling in the gaps in the tool
instead of focusing on the main task. By using multiple tools there are
rarely gaps because there is almost always a tool for the job.

The second common argument for using one tool is cheaper developers. If
my application uses Perl, PHP, Ruby and some shell scripts I would have
to hire someone that knows all four! If I only use PHP then I can hire a
cheap PHP developer. To me this is just an argument about hiring cheap
developers vs. experienced developers. Any experienced developer will
have worked with many tools. That experience will speed up your
development and lower your costs no matter how many tools you are using
(1 or 5) because the experienced developer will have insights into the
design and development that no “one-tool” developer will have. Obviously
the experienced developer will cost more but in my experience the
results produced are well worth the cost and generate an overall cost
savings.

Of course this advice this must be used with common sense. If no tool
does the job you need then develop with what you are most familiar
with/use the most. Don’t use unnecessarily many tools. My guess is that
2 or 3 tools will cover most of the gaps and provide the foundation to
develop most anything.

Eric

Eric A. wrote:

Bob Y. wrote:

My department is in a battle right now. We have some very por PHP
people and very pro Rails people. The php guys make a good argument

Why one or the other? Use the appropriate tool for the job or your
wasting money and time.

Unless the tools are so far apart in their target, the economics of
software (or at least my understanding thereof) suggest that you’re
likely to reap some benefits by not having too many different tools
floating around.


David N. Welton

Linux, Open Source Consulting

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs