There's a 3rd option - code generation.

I have worked on an in-house utility to generate data entities and data
access code directly from the database schema, based on XSLT templates. It's
also possible to go the other way i.e. generate your database schema from
'metadata' in your code (although I think that has limitations when
considering changes to the schema - OK for creating new empty databases).

There are a number of 3rd party and share/freeware tools around -
"Codesmith" has been around for a while, and I have heard good reports about
"LLBLGEN".

I will choose (i) for compatibility. These data in database will be easily
re-used and better understand by other applications. I prefer serialization
when pass object between layers. To save it in database, I think (i) should
be a better solution.

Luke

There are so many times when having specific data in specific fields within
the DB is advantageous. Consider joining across tables...

Also, relational DBs really are designed (up until now) to house data held
within specific fields. There are many functions available to you and
performance optimisations that you will only benefit from if you break your
object apart and handle it's loading/unloading to db.

With the onset of SQL 2005 however, there may be lots of reasons to store
this stuff within an XML field. XQuery will means that you can efficiently
get to the stuff contained within your XML structures and use the specific
elements/attributes etc. to join across other DB tables. There is still going
to be processing overhead to do it this way however it will be reduced and
better integrated into the DB software. Certainly, the decision has to be
based on how much more convenient it would be to store the data in XML and
avoid changes to the DB schema Vs difficulty and performance.

You might also like to step outside the relational DB zone and consider some
of the object databases now available. Some of them are pretty good and this
issue becomes a mute point when used properly.

The last option you have is to provide an additional layer to your app to
handle ORM (Object Relational Mapping) and actually modify/extend your DB
schema as your requirements evolve. This may not be the best solution though.