In one of my blogs I had talked about the perils of matching the domain model with the data model and how to solve it using Toplink. In one of my weekend projects I also talked about Twitterizing your Sunbird. Sunbird uses a small footprint of its' data-model based on the open source, open standard SQLite. And its' database is stored in a sdb file. So lets marry Toplink with the SDB file. Yes you can do that and its fairly simple and straight forward. So if you have a small data model with fewer number of tables and you want to run on a small database like what is used by Sunbird then let Toplink handle it. The Toplink workbench has a feature to recreate the data model on a database based on it's descriptors. So be it any complex data model, it can be recreated on any other database. But hold on.. Is it that simple? SDB does not support any Foreign keys and two tables can not be joined by any such relationships. Except the primary key constraint, no other constraints can be created in SDB. Big problem huh? No. Toplink does not care because the constraints it bothers about should be present in its' Object graph and not necessarily on the database. Remember the small check-boxes in the workbench asking if you want to create it on a database? And here is where the real power of Toplink comes from. The other example would be to create foreign key constraints on a database View? Even though logically it behaves like a table but a view is nothing more than a select statement providing a limited view of a certain data set. In Toplink though a view can be imported as a table descriptor. So, even with a view we can create foreign key constraints which does not have to exist in the database and in this case not even allowed. You would also watch out for default sequencing. Many small size databases like SDB do not support Native Sequencing and this would need to be changed in Toplink if not supported. What a better way to make your application agnostic to your database?