Un-validated Transaction Table requiring update

Mark Vickers

Un-validated Transaction Table requiring update
Folks,
There are always these unexpected requests....

"We need to store an orders transaction file which the user may want to
update."

After asking the obvious questions :-
this file could contain invalid data
there are related tables, but since the data has not been validated, I
could not have any RI
they also want an update log file (I haven't offered any solution here yet
as I am still grappling with the idea of having something dirtying up my
creation :-)

My reaction would be that this should be in a flat/VSAM file and only the
valid orders should be inserted into the database.
All existing tables have at least a primary key.
This would have to in order to allow updates and I can always rig
something to make them unique, but...
I am just going on my gut, but I really don't want this in DB2 - am I way
off here ?

thanks,
Mark.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Bell

Re: Un-validated Transaction Table requiring update
(in response to Mark Vickers)
A couple of business questions
how much effort is it to recreate the order information?
how critical is the data if an order gets dropped and doesn't get completed.

I had a design where we had an incomplete transaction table that could be
processed multiple times as the order entry collected the data. As you
would expect all fields were nullable, no RI , and the actual completed
transaction had a completely different home.

Now a technology question, do you really want incomplete transactions in
VSAM with all the headaches of recovery, rollback, etc. If the data is just
as critical to the business as the processed transactions, then it deserves
to be in DB2.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Mark E Vickers
Sent: Thursday, January 05, 2006 1:19 PM
To: [login to unmask email]
Subject: [DB2-L] Un-validated Transaction Table requiring update

Folks,
There are always these unexpected requests....

"We need to store an orders transaction file which the user may want to
update."

After asking the obvious questions :-
this file could contain invalid data
there are related tables, but since the data has not been validated, I
could not have any RI
they also want an update log file (I haven't offered any solution here yet
as I am still grappling with the idea of having something dirtying up my
creation :-)

My reaction would be that this should be in a flat/VSAM file and only the
valid orders should be inserted into the database.
All existing tables have at least a primary key.
This would have to in order to allow updates and I can always rig
something to make them unique, but...
I am just going on my gut, but I really don't want this in DB2 - am I way
off here ?

thanks,
Mark.

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mark Vickers

Re: Un-validated Transaction Table requiring update
(in response to Mike Bell)
Mike,
It is critical, and we need a log of any changes to the original
transaction.
I will make sure there is a purge process in place too.

These and the recovery options are reason enough to allow this into DB2.
thanks,
Mark.




Mike Bell <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
01/05/2006 02:03 PM
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: Un-validated Transaction Table requiring update






A couple of business questions
how much effort is it to recreate the order information?
how critical is the data if an order gets dropped and doesn't get
completed.

I had a design where we had an incomplete transaction table that could be
processed multiple times as the order entry collected the data. As you
would expect all fields were nullable, no RI , and the actual completed
transaction had a completely different home.

Now a technology question, do you really want incomplete transactions in
VSAM with all the headaches of recovery, rollback, etc. If the data is
just
as critical to the business as the processed transactions, then it
deserves
to be in DB2.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Mark E Vickers
Sent: Thursday, January 05, 2006 1:19 PM
To: [login to unmask email]
Subject: [DB2-L] Un-validated Transaction Table requiring update

Folks,
There are always these unexpected requests....

"We need to store an orders transaction file which the user may want to
update."

After asking the obvious questions :-
this file could contain invalid data
there are related tables, but since the data has not been validated, I
could not have any RI
they also want an update log file (I haven't offered any solution here yet

as I am still grappling with the idea of having something dirtying up my
creation :-)

My reaction would be that this should be in a flat/VSAM file and only the
valid orders should be inserted into the database.
All existing tables have at least a primary key.
This would have to in order to allow updates and I can always rig
something to make them unique, but...
I am just going on my gut, but I really don't want this in DB2 - am I way
off here ?

thanks,
Mark.

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select
"Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email]
Find
out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm