| |
I am currently working on a Handheld application which will interface with a web application via SOAP. We are currently in the design phase. Over the past years, I have grown from a pure relational database guy, to an Object Oriented Developer. I am learning a lot about the design decisions I used to make from a relational point of view. My Handheld application is OO, and the backend is Relational. So I want to synchronize data using objects, and the client is more comfortable just sending data tables of records which have changed.
We had a confusing, yet productive design meeting yesterday. The main issue revolved around Relational Integrity. There are some items which I would view as a complete object and I wanted the webservice to return full objects. However, it is possible to change a single field of data, such as a status label within the database which could affect hundreds of records. Downloading 100 changed objects is not efficient, especially on a handheld.
We netted out with a denormalized intermidiate stucture, which collapse some dozens of tables into less than 15, but ended up with more than the 5 objects which will be utilized on the handheld. This provided us with efficiency, and prevented the handheld from requiring a relation datastore.
11:45:17 AM 
|
