MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » October 2012

RE: Pros and Cons of DB defined Referential Integrity Constraints



fixed

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?"


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Friday, October 19, 2012 4:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: Pros and Cons of DB defined Referential Integrity Constraints

I can think of one reason to avoid putting RI in the DB: when you do
not have a clear object definition.  Very common in the "quick and
dirty" world I work in.

For some reason, this comment keeps popping up in my mind. I've tried mulling it over, but I don't quite get it. Does it have to do with OO languages and coding paradigms? I could see the point if a database layout was not clearly defined; don't put effort into RI constraints.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.








Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact