Re: data structure complexity vs. application maintenance cost
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Wed, 28 Feb 2007 22:05:22 GMT
Responding to Parker...
So one typically isolates the persistence access in a subsystem that is
constructed after the rest of the problem is solved. The interface to
that subsystem is based on the problem solution's needs for data and the
subsystem exists to convert between the solution view and the
persistence view. Then, given that the views are decoupled, it becomes
relatively easy to design the persistence view (e.g., RDB schema) that
works best.
I have to concur with Topmind's and JXStern's comments. It's bad
advise, in general, to build up a complete representation of data in
the application's space, with code, along the lines suggested here.
The RDBMS is a tool for managing data access. It goes far beyond
persistence, it's scalable and fault tolerant in the way that many
home grown approaches are not, and provides a logic based querying
capability that is richer than the typical home grown code based
filter. Managing large amounts of state in the application is not
usually a good idea, there are tools for that. Generally speaking,
the idea in software assembly these days is to leverage tools, where
appropriate.
I'm not suggesting one should replace the RDBMS or not utilize the high level tools for accessing it. I'm also on record as saying that RAD IDEs are the way to go for CRUD/USER processing (as opposed to OO development from scratch). But once one is outside CRUD/USER processing there are a lot of reasons for encapsulating the DB access.
A DBMS is a tool for managing GENERIC data access. Once one is outside the realm of CRUD/USER processing, applications are highly tailored (read: optimized) to solving very specific problems. In such situations the view of the data is quite likely to be different than the generic RDB schema view. Converting the views is a different problem than the customer's.
Much more important, though, is navigation among the data. Relationships in an OO application are instantiated at the object (tuple) level rather than at the class (table) level. That requires an entirely different model for data access that is tailored to in-memory navigation (address-based identity). Trying to use a SQL-style query/join/index search model for data access within the application solution would be lunacy from a performance viewpoint. So one needs to convert from the RDB view of relationships to the OO view and that conversion needs to be encapsulated.
In addition, DBMSes have their own set of unique problems for efficient data access in a multi-user environment that often require unique handling on the application side (e.g., anticipatory caching, batched transactions, etc.). One does not want to interleave those workarounds with the logic of the problem solution so, again, one needs to encapsulate them.
In my career I've watched five different storage paradigms dominate. Every paradigm switch caused great gnashing of teeth because application solutions were inextricably married to a particular paradigm. The RDB paradigm has lasted longest but I think it would be naive to assume that it won't be replaced. (Even now we have OODBs and XML servers nibbling around the periphery.) It would be even more naive to believe that SQL will remain the primary interface to RDBs or even that SQL drivers were truly portable.
It costs very little to isolate those mechanisms from the problem solution so that when they change the problem solution remains untouched. Limiting the scope of rework is only one advantage. Perhaps more important is that one can be completely confident that the application solution still works properly because one didn't need to touch it when the storage side changed.
Encapsulation of those mechanisms provides the best of both worlds. The solution to the customer's problem is not distracted by the mechanisms and yet one can employ all the tools you referenced /within/ the DB access subsystem to facilitate the access. But perhaps the biggest advantage of isolating the DB access is design reuse, which provides even greater benefits than those tools.
Once one sets about developing a subsystem dedicated to, say, RDB access it doesn't take long to realize that the dominant abstractions are things like Schema, Table, and Query rather than problem space abstractions like Customer and Account. One can encode the RDB invariants and specify the particular access via configuration data, just like one does routinely with GUIs. That allows one to reuse the DB Access subsystem across applications. Now the application developer can access the RDB for a new application without touching the code at all; the developer just provides the identity mapping between the interface and the schema as external configuration data. IOW, one gets to do for complex applications what RAD IDEs do for CRUD/USER applications -- hide the grunt work entirely.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- data structure complexity vs. application maintenance cost
- From: fireball
- Re: data structure complexity vs. application maintenance cost
- From: H. S. Lahman
- Re: data structure complexity vs. application maintenance cost
- From: Daniel Parker
- data structure complexity vs. application maintenance cost
- Prev by Date: Re: Creating Full Name from given, initials, sn, when some might be null
- Previous by thread: Re: data structure complexity vs. application maintenance cost
- Next by thread: Social networks
- Index(es):
Relevant Pages
|
