Thunderbolt labs have a great post on why sharing the database is an SOA
anti-pattern. I agree with them. I've seen Rails applications
that share a databse with different subclasses of
ActiveRecord::Base in each
for the same table. Some fields were used by one codebase, some by the other.
Migrations were spread out across the different codebases. This is an example of
broken encapsulation (and masochism).
You could make this work by wrapping your subclasses of
into a private gem and using that to access the shared database instead of
accessing it directly. The gem respository could be the place to store your
database migrations for that table.
Using a library instead of accessing the database directly gives you the performance benefit of using the database and keeps the API encapsulated. If you were to change the library to use a JSON based HTTP API or a third party web service instead of the database, client code wouldn't know the difference.