Most large organizations have internal database naming standards. These standards are often created in-house by the senior employees and can vary widely between organizations.
Ruby on Rails makes several assumptions about the database structure. Some examples include an id column named (gasp) id or a foreign key column named 'table name'_id. Some of the Ruby on Rails plug-ins also make assumptions about the structure of the database. Acts As State Machine expects the model table to have a state column where the state is stored as a string.
Obviously, conflicts can occur between corporate standards and Ruby on Rails assumptions. Ruby on Rails provides you with the flexibility to support many of the (often bizarre) corporate standards. However, some database decisions are not easy to change. For example Acts As State Machine (AASM) to my knowledge does not allow you to abstract the states to a lookup table. And, having a string repeated in a single table can cause some DBAs to have nightmares.
A solution to this problem is to use views when working with an underlying database structure that you cannot fully control. To solve the AASM issue you can provide an updatable view that returns the state as a string. When an update needs to occur on the view you simply update the underlying table to use the correct key from the state lookup table.
As Ruby on Rails gains acceptance into larger enterprises I expect to see more scenarios where these types of issues appear.