Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 2 Jun 2006 08:55:35 -0700
Robert Martin wrote:
> However, the data cannot remain in the DBMS for its entire lifetime.
> The RNA has to leave the nucleus and get out into the cytolasm to do
> it's work. And out there in the cytoplasm the integrity of the data is
> no longer the responsibility of the DBMS.
Both the genetic and the distribution network analogies are so bad as to be useless. Data and information do not "move" in any meaningful way (just as systems are not "constructed" in the same sense as either a car or a building). The various DBMSs in a federated or distributed architecture all have responsibility for the data integrity; if an application "decides" to create bad "data", it's not data and will be unacceptable when saved. If it's merely sent to another application, the same constraints should apply (whether implemented or not). If it's transformed, then presumably a derivation of the integrity constraints is still applicable.
All of this argues for the proper (and automated) propagation of integrity constraints, rather than their absence. Granted that this is some way off, but it's a goal to be realized rather than abandoned.
> So applications have an equal responsibility to maintain the integrity
> and security of the data while they control that data.
They don't control the data. It's not handed off like a hot potato.
> But this is a side issue. The issue that started this feeding frenzy
> of self-contratulatory ad-hominem arguments was the notion that the
> design of application programs should be so strongly decoupled from the
> DBMS as to afford the replacement of the DBMS with a completely
> different technology.
And here the word "technology is key. Is it useful to view the DBMS as something that should be replaceable regardless of the concepts in which it "renders" business rules? If so, you may as well just serialize to a file (see Prevalyer for a degenerate example, though not as degenerate as some) and give up.
At some point the application has to know what it's getting from a data source. Is it just a stream of bytes? Is it an instantiated object? Is it a low-level data type like a linked list or a hashmap/dictionary? Is it (shudder) XML? What an application receives from a service does matter, and relations are a much more expressive gift than most other alternatives.