Re: Pros and Cons of DB defined Referential Integrity Constraints

Thanks for your detailed response, Gary. It's always interesting to hear about the types of data and processes that organizations may be dealing with. I can relate to the idea of a "data DMZ" which might consist of say hierarchically structured XML message formats, or some other intermediate data exchange format.

Regarding your question about whether OO or procedural languages might be better for handling data exchange, my responding to that could be opening a can of worms. One's selection of language normally has more to do with culture, platform, experience, and environmental factors than with the processing that needs to be performed. We use RPG for data exchange.

-Nathan


________________________________
From: Gary Thompson <gthompson@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, October 23, 2012 7:21 AM
Subject: RE: Pros and Cons of DB defined Referential Integrity Constraints

Nathan,

A typical "quick and dirty" project model is:
I have fairly complete knowledge of the system used where I work,
but we do not have source code, and do not control the database.
On the other hand, like most companies, we exchange data with
third-party service providers and customers which often appear
as "black box" systems. 

One example:

We have a request to process data from a web-based routing tool.

We send this third-party product and daily sales detail.

The third-party tool prepares an optimized delivery route complete
with an order for the product needed for a day's worth of deliveries
to the customer outlets predicted to need product.

Delivery route data is exposed to my company as a web service.

The request from our sales department is to convert delivery route
data into product orders in our local system.  These product orders
are then processed to create "loads" for our daily delivery process.

For sure, we enforce as much referential integrity as possible in the
db files we create to support functions such as this. 

On the other hand, we cannot control inputs/output from/to trading
partners, so we work with a collection of "islands" of data where the
files, to me, have a poorly defined object model.

I think of these islands as belonging to the "data dmz"

So, it has less to do with OO languages and coding paradigms and more
to do with exchanging data between different systems, some of which do
not expose their object model.

A question I would like to hear your comments on is:
"Which makes the better tool for handling data exchange; OO or a modern procedural language?"