1

I'm currently on the fence on how to implement my models. Right now I'm using polymorphic relationships, but it feels so wrong, though very convenient. I feel like I should be making use of database level integrity enforcement as an added layer of security.

Am I a grandpa for questioning the application layer? Please discuss.

I did find this post, but it is not Rails specific Possible to do a MySQL foreign key to one of two possible tables?

Community
  • 1
  • 1
Dex
  • 12,527
  • 15
  • 69
  • 90

3 Answers3

1

It all depends.

If your application is the only one that access the database (e.g. there are no other tools writing to it), you can verify data integrity in your application code.

There are some things, however, that are still best done in the database. validates_uniqueness_of is a good example here. Two app instances may report a given value unique, but there may be a race condition. Having a unique index in your database here is good practice.

I always handle integrity checking in my app code, using indices for uniqueness constraints. I don't bother with foreign_key relations, I let ActiveRecord handle that.

Ariejan
  • 10,910
  • 6
  • 43
  • 40
  • 2
    Very bad idea. There will eventually be other things that affect your database and when you go to a new application sometime, do you really want to recreate all the data integrity rules again. It is stupid and short-sighted to let an application maintain datba integrity. I have had occsion to see hundreds of s datbases and have never seen one that did not have dat integrity maintained by the database that actually had data integrity. Very poor idea to try to maintain in datbase and not set Fks etc. – HLGEM Nov 15 '10 at 14:56
  • 3
    It's not short sighted. What if you need to swap to another database system like Postgres or some NoSQL solution later? What if you want to use database sharding with MySQL? Let me know how your database-oriented data integrity holds up then. – Ariejan Nov 15 '10 at 15:22
  • 1
    Are you actually saying its inexpensive to switch databases regardless of the framework? Those kinds of rash and crazy decisions post initial implementation are way too dangerous, whilst i know that Ruby migrations make it easier, there are other things to consider - such as the transfer of data, whether the database does exactly as the other database does (e.g. differences in like / group by / varchar limit truncation / the way activerecord works with the new database wrt type casting on joined attributes) and is not something that I would do, ever. – Omar Qureshi Nov 15 '10 at 18:40
  • 2
    Being agile, I want to use the right tool for the job. Apps grow, expand, shrink, mutate. Where a MySQL database work initially, it might not work so well later on. Take a look at all the big 'agile' project like Twitter and Github. They adapt their tools to their needs. Either way you'll have work to do if you migrate to another system. – Ariejan Nov 16 '10 at 21:06
1

There's always http://www.postgresql.org/docs/current/static/ddl-inherit.html

I never got round to it, but, was working (during a boring commute) on trying to make that work nicely with Rails.

Omar Qureshi
  • 8,963
  • 3
  • 33
  • 35
0

I've been keeping up with this and I've come up with a hybrid solution.

I think the default Rails polymorphism functionality is very well suited for rapid prototyping. But for a long term solution, I've implemented by own polymorphic association using an intermediary table (e.g. Commentable, Votable). I can't find the post, but Bill Karwin points this method out in several answers on this site.

I don't plan on sharding, but if I did, I think Rails' default solution would be a good one.

I wrote my own Mixins to emulate the default Rails polymorphism functionality. It was a little tricky with foreign keys added in, or when adding the relationship after the table has been populated, but things seem to operate smoothly still.

Finally, my project will eventually have multiple services running analytics on an undetermined backend, most likely Java. Referential integrity aside, having a standard relational model is best suited for my needs.

In Short, I think it does depend, but in 90% of cases, having DB level integrity is best.

Dex
  • 12,527
  • 15
  • 69
  • 90