Each Active Record is responsible to saving and loading to the database, and also any domain logic that acts upon the data. This may be all the domain logic in the application, or you may find that some domain logic is held in Transaction Script s with common and data-oriented code in the Active Record . Type the fields the way the SQL interface gives you the data - don't do any conversion at this stage. You might consider Identity Field , but it may also be fine to leave the foreign keys as they are. You can use views or tables with Active Record , although obviously updates through views are usually limited.
Views are particularly useful for reporting purposes.
The getting and setting methods can do some more intelligent things. They can convert from the SQL oriented types to better in memory types. In this pattern the tables are a convenience, but they don't hide the fact that a relational database is present. As a result you usually see less of the the other object-relational mapping patterns present when you're using Active Record . Active Record is a good choice when your domain logic is not too complex, but there's still value in having behavior that's oriented around the records rather than entirely around the transactions.