Serializing vs. persisting to database?

  • Thread starter Thread starter Dave Veeneman
  • Start date Start date
D

Dave Veeneman

When does serializing objects make more sense than persisting them to a
database? I'm new to object serialization, and I'm trying to get a feel for
when to use it.

Here is an example: I'm writing an accounting application. I have a chart of
accounts in the form of a containment hierarchy. A GeneralLedger contains a
number of Accounts, and each of these Accounts can contain a Aubledger,
which contains its own Accounts, and so on. The chart of accounts is loaded
when the app initializes and stays in memory until the app terminates. I
also have lots of transactions, which are read from the database and mapped
into Transaction objects as needed, using the chart of accounts to filter
the selection.

For a moment, disregard the database design issues involved. Does it make
sense to serialize a containment hierarchy like the chart of accounts,
rather than persisting it to the database? Is that how one would normally
use object serialization?

Thanks in advance!
 
Dave Veeneman said:
When does serializing objects make more sense than persisting them to a
database? I'm new to object serialization, and I'm trying to get a feel for
when to use it.

Here is an example: I'm writing an accounting application. I have a chart of
accounts in the form of a containment hierarchy. A GeneralLedger contains a
number of Accounts, and each of these Accounts can contain a Aubledger,
which contains its own Accounts, and so on. The chart of accounts is loaded
when the app initializes and stays in memory until the app terminates. I
also have lots of transactions, which are read from the database and mapped
into Transaction objects as needed, using the chart of accounts to filter
the selection.

For a moment, disregard the database design issues involved. Does it make
sense to serialize a containment hierarchy like the chart of accounts,
rather than persisting it to the database? Is that how one would normally
use object serialization?

Thanks in advance!
Click to expand...

I think you'll find that the biggest factors in your decision will be what
you want to -do- with the data, and not so much the structure.

If you're answering "Yes" to the following questions, it should point you in
the direction of using a database:

Is the data going to be shared among multiple users?
Might they access the data concurrently?
Do you want robust searching/filtering capabilities?
Are you going to be dealing with large numbers of records that may require
data paging?
Do you want to easily export your data to different formats?
Do you think your data models might change occasionally?
Is your data relational in nature, and do you want to leverage that
functionality in your code?

Erik
 
Hi Dave!
Use the DB to store your physical data i.e. the numbers and
transactions and you can (if you wish) serialize your objects to a
file. However, this object hierarchy is created somewhere, isn't it,
and can't this process be replicated at startup? Serializing an object
to some stream (file, network etc) will let you put the object with
all it's attributes and values in a binary file. You must retrieve
your objects in the same order as they are stored to the file.

- Peder -
 
Dave,

I would put a database underneath all of this. There are just too
many occaisions where I find having a SQL underbelly makes the most
sense over the life of an application. I like XML for certain kinds
of tasks, but not as the basic storage form for all of my
application's data.

Here's a prediction: your posting is going to start a lengthy and
lively debate!

Les Matheson
Integral Concepts, Inc.
http://www.ivsds.com

"Reality is that which does not go away when you stop believing in
it."
- Philip K. Dick
 
Dave,

I rarely see a need for serialization, but on occasion it comes in handy.
And sometimes it's even handy to persist an object in a DB using
serialization!

For example, I have an application where the user fills out an extensive
multi-page form of query specifications, which varies depending on the
report or export being set up. Out of potentially hundreds of data points,
only 2 or 3 are relevant for searching / filtering / sorting in the DB, so
those items are replicated in table fields. Other than that the entire
object is binary serialized into an image field in SQL Server.

The advantage is that any type of query (for various kinds of reports and
exports) can be stored and recalled, and I don't have to worry about the
details or provide a different table schema for each type of query or use
some other kludge. They all go into the same Queries table, which has a
QueryTypeID and the BLOB containing the query specification object (which is
just a SortedList of HashTables of strings).

--Bob
 
Back
Top