Rails data integrity : To trust or not to trust

In the midst of my Utopian Rails world, something prompted me to rethink using the ActiveRecord associations heavily in Rails. You may have guessed right, it is related to data integrity.

Rails enforces “data integrity” at the application level by forcing you to use certain conventions.
Semantics are built in within ActiveRecord to check for patterns in the database to enforce those integrities

In traditional applications, data integrity is maintained in the physical layer of the database.
This is achieved through old school SQLs and database design principles such as using foreign keys and such. In the enterprise Java world, integrities are well looked after by programmers manually developing SQL statements to cater for it.

In Rails, you define these in the application level. The question remains: Can you actually trust Rails to fully maintain your data integrity in a large software environment. This may be okay for blogs and forums, but what about an enterprise software environment where you can have potentially ultra complex relationships defined…..

Now that’s a rethink of relying too heavily on Rails to maintain data integrity….
Overall, I am more comfortable with rules clearly defined in SQL scripts rather then having to imply the relationships by checking table fields and also reading the definitions of the logical models in Rails….

either that..or I am just really old school…

Share/Save/Bookmark

4 Responses to “Rails data integrity : To trust or not to trust”

  1. Yo Mike, on a somewhat tangential note - not sure if you ever took a course on Siebel CRM back at the hell hole - apparently Siebel - to stay portable across DBs decided to do ALL referential integrity at the app level. Hence, nobody can touch the database (unless of course you want to end up calling Siebel Level 20 support…).

  2. Hey Kamal,

    I definitely didn’t know about this, but it would make absolute sense if this concerns portability.
    We tried looking into the database itself in the CRM and it actually has a bunch of PL/SQL scripts for manually maintaining referential integrity.

    Of course you can’t touch the scripts as that constitutes “hacking”…what I think is the bunch of rules defined at the app level that triggers these PL/SQL scripts.

    Good point out. :D

  3. Hmm, didn’t realise that.. that’s silly - so they use PL/SQL which is very db-specific (more so than plain ol SQL statements) - but decide to use the app for everything else… okay so I’m confused.

  4. It would certainly make sense to have PL/SQL (Oracle) since Siebel is owned by Oracle now… :D

    The reason I knew was one of my ex-tasks involved dissecting parts of the CRM to find a solution to a problem in production… :+

Discussion Area - Leave a Comment