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? -- Posted via http://www.ruby-forum.com/.
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 Yann <yannman@gmail.com> 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. > 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? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
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. -- Posted via http://www.ruby-forum.com/.
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
--
Posted via http://www.ruby-forum.com/.
On 7/12/06, Bob Yann <yannman@gmail.com> 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.
On 7/12/06, Bob Yann <yannman@gmail.com> 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 Yann 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 argumentWhy one or the other? Use the appropriate tool for the job or your wasting money and time. Eric
Bob Yann 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. > 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.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 Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
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 -- Posted via http://www.ruby-forum.com/.
Eric Anderson wrote:> Bob Yann 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 - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/
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