Comments on: Database Management Systems - Occasionally Connected Applications http://www.panttaja.com/jim/2007/06/04/database-management-systems-occasionally-connected-applications/ Creating what's next Tue, 06 Jan 2009 06:04:46 +0000 http://wordpress.org/?v=2.2 By: mpanttaja http://www.panttaja.com/jim/2007/06/04/database-management-systems-occasionally-connected-applications/#comment-2 mpanttaja Wed, 06 Jun 2007 05:17:41 +0000 http://www.panttaja.com/jim/2007/06/04/database-management-systems-occasionally-connected-applications/#comment-2 I think that this is a case of a new technology path running up against an older, fairly well-known problem. But it is not necessarily a straight-forward set of solutions and I think it will be interesting to see if the new network architectures lead to easier solutions than we were able to build in the 90's. I think it would be interesting to create a set of "distributed dataspace" attributes and use them to define and clarify an orthogonal set of use cases. This is all key, of course, to how much the application has to be redesigned and rebuilt to meet these requirements. What else needs to go on this list? Data Ownership (the obvious) Identity of the primary datastore of record Which applications can change data? Can you control single threading of access? Is data element ownership isolated? Band-width criteria vs data sizing Is the relative bandwidth generous enough to enable simple over-right replication solutions? Or do we need to be stingy with our messages and keep ownership and time stamps on everything. Recovery requirements Security requirements Changing cross table validations and references Etc. From combinations of such factors perhaps we can build use-cases, design patterns, and clear solution patterns. As you point out, it's one thing to say you can enable an application to work offline and on the desktop, but it's another if the application is about persistant data. But it is also an interesting design challenge---which is always fun. I think that this is a case of a new technology path running up against an older, fairly well-known problem. But it is not necessarily a straight-forward set of solutions and I think it will be interesting to see if the new network architectures lead to easier solutions than we were able to build in the 90’s. I think it would be interesting to create a set of “distributed dataspace” attributes and use them to define and clarify an orthogonal set of use cases. This is all key, of course, to how much the application has to be redesigned and rebuilt to meet these requirements.

What else needs to go on this list?

Data Ownership (the obvious) Identity of the primary datastore of record

Which applications can change data?

Can you control single threading of access?

Is data element ownership isolated?

Band-width criteria vs data sizing Is the relative bandwidth generous enough to enable simple over-right replication solutions?

Or do we need to be stingy with our messages and keep ownership and time stamps on everything.

Recovery requirements

Security requirements

Changing cross table validations and references

Etc.

From combinations of such factors perhaps we can build use-cases, design patterns, and clear solution patterns.

As you point out, it’s one thing to say you can enable an application to work offline and on the desktop, but it’s another if the application is about persistant data. But it is also an interesting design challenge—which is always fun.

]]>