I was just watching a preview of a session at Aloha on Rails called "You're Doing it Wrong".
In the short preview, he mentions using ActiveRecord models as enumerations (I assume he means plugins like enumerate_by). This seems like reasonable idea to me, what are the problems? Is it just the overhead required by the additional objects?
Thanks
As he said, its about static enumeration he has problems with. Why would want to made a database query for some static data that you can store in named constants?
Also, some developers code for the future. Its about coding to the requirements for now while keeping the design closed for modification and open for extension, if at all the requirement extends in future. Otherwise you would be spending time, effort and eventually money on something that client has not really requested to have. Scalable design is one thing and design for future requirements is other. While the former one can be extended to the later one if needed, later one is not really needed at this point in time.
He's a bit hyperbolic and idiomatic in his presentation. His point is sound, though.
There is development overhead to putting static data into a database: you'll need to make sure that all migrations are run in all environments (including every time you db:test:clone), you'll need to load the data every time you work with your code (eg, even in irb), you may run into load order problems. In short, it's not free, and we don't want to incur unnecessary development and support costs.
However, there can be benefits to doing it. The data may want to be shared between code written in different languages; the code might be complicated and require an expensive test cycle before each and every deployment; you may want to create database constraints the data; you may have extensive or structured metadata you want to associate with the enumeration; and so on.
These conditions aren't common, though. For most enumerations, named constants, a hash, or even just a convention using symbols is sufficient.