I would choose a different, though more chumbersome, approch, which is
based on seperating as much as possible.
------code------
interface RecordPersistor{ //not public - package visibility only
 persist(Record record);
}

class RecordDBPersistor implements RecordPersistor {} //for example

public interface Record { //all your data getters/setters }

class RecordImpl implements Record { //package visiblity
 public RecordImpl(RecordPersistor rp){/*saves the rp object*/}
 public persist(){ rp.persist(this);}
}

public RecordFactory {
 Record createRecord(/*params, persist method*/){ return new
RecordImpl(new RecordDBPersistor());} //for example
------code------

This is a valid perspective but for me the key point is that the Record  
does not need to know how it is persisted.  Moreover, what if you want to  
persist it in more than one way?  Say you have a persist() method that  
writes the record to the database.  Then somebody decides that it would be  
a good idea for some records to be saved as XML under some circumstances.  
Then you have to add a persistXML() method.  Then maybe you need a record  
to be written to the file system as a serialised object.  So you add  
another method.  The result of this is that the Record class needs to know  
exactly how to do each type of persistence and you've had to modify and  
add complexity to the Record class for each one, even though the concept  
of what a Record *is* has not changed.  Not only that, you now have three  
differently named methods.  So the calling class that invokes the  
persistence needs to know about each of the persistence methods provided  
so that it can invoke each one.

If instead you have a RecordPersistor interface (like the one described in  
one of the other posts in this thread) and have one implementation for  
each type of persistence (DB, XML, serialisation), then each will have an  
identically named method that can be invoked without any knowledge of  
*how* the persistence will be achieved.  So your code that saves a record  
can just iterate through a list of persistors and call the persist method  
on each (passing it the record to be saved).  Now when you add a fourth  
persistence implementation to the list of persistors, nothing has to  
change.  Neither the Record class itself nor the code that invokes the  
persist methods has to know anything about the new persistence.  It  
doesn't matter whether it is uploading the record to an FTP server,  
dumping it to the printer or doing something that nobody has yet thought  
of.  Whatever new strategy you add will be supported without requiring  
anything else to change.

It should be as big as it needs to be, no bigger.  Beware of artificial  
limits applied arbitrarily.

Dan.