Chris Downey

From RailsGuides: Active Record and Referential Integrity

The Active Record way claims that intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database, are not heavily used.

That is a very different way of designing systems than I’m used to doing and is interesting to think about: have I been pushing too much intelligence into the database?  I think so.  My current (at work) system has many stored procedures that contain most of the business logic and, at best, can be tested only indirectly.  In the July 2011 Thoughtworks Technology Radar (p.10), they point out that:

Programming languages commonly used to implement stored procedures lack expressiveness, are difficult to test, and discourage clean modular design.

I like how Rails is forcing me to think of physical structure and logical design at the very start of a new system; for legacy systems, thinking about how to integrate Rails is bringing clarity to some fundamental design flaws.  The trick will be: how to gracefully move into an improved architecture by bringing in Rails and pushing out a thin Java DAO layer that really doesn’t do much except transfer data between the Flex client and the database?

To learn Rails, I’ve started working on integrating it with a production system.  Getting connected to SQL Server 2005 was a bit tricky – this guide helped move things along.  Getting the ODBC connection string correct was a pain.

Everything I’ve seen so far on learning Rails focuses on building new apps.  Its not clear to me how to integrate rails into an existing production system.  The first problem is how to handle migrations? If I skip a migration because the table exists, what is the impact of not having the Rails-created fields id, created_at, updated_at in the table?