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?
