RE: Design Issue - Quick response appreciated

Chris,

Thanks for the suggestion. In our case, once a record is inserted, we cannot update the record. If any column need to be changed, then, we insert another record which would contain all the data of the columns of the previous record + the data of the changed column (or columns).

I am toying with the following idea. Please point out if there are any probs with this.

1. I would create a surrogate key whenever a record is inserted and then insert this record in the transaction table with generation number 1 (please see item # 3 below).
2. I would maintain a separate table - say - KEY TABLE with the surrogate key + all the keys that uniquely identify the record.
3. I would also maintain a table - say - GENERATION TABLE. The columns in this would be - surrogate key + generation number.
4. Whenever, a record is being inserted, I would check key table. If no record with the keys are present, then, I would insert a record in the key table + insert one record in GENERATION table; in this table, generation number would be 1 for this record.
5. If a user tries insert a record which is already existing in the KEY TABLE, then, I would update the generation number column in GENERATION table.

In the above way, whenever, I want to get all the previous records, I would go to GENERATION Table and then get the generation number for that surrogate key. (I would be getting the maximum generation number because I always updating this column with the last generation number). Once, I know the last generation number, then, it is a question pulling all the records with the surrogation key + (all the generation numbers).

Thanks,

Rao

-----Original Message-----

Sent: Monday, September 24, 2001 3:01 PM To: Multiple recipients of list ORACLE-L

Rao,

I had a similiar requirement for a past project, we added a STATUS column to the tables, the "A" is the current or active record, and "I" were the inactive records. Obviously, the software was coded to retrieve only active records. Since we used surrogate keys this setup was not a problem. We also had a problem with developers forgetting to check for active records, which resulted in some early bugs, so we ended up creating views with status = 'A' hardcoded.

2) So with the above in mind you can retrieve all the records based on the four columns. You can tell which one is active or current based on the STATUS column. Obviously, you can throw in some date and userid columns in there. Obviously, you can keep as many "history" records as you want, there easily identified.

HTH. Chris

-----Original Message-----

Sent: Monday, September 24, 2001 2:30 PM To: Multiple recipients of list ORACLE-L

Chris,

Thanks for the reply.

This application is a securities processing system. Once a record is inserted into the table, then, as per business requirement, no changes could be made to an already inserted record due to audit regulations. Hence, if any change is required for an already inserted record, then the user inserts another record with a change.

2. In my case, a record is identified uniquely by a combination of 4 columns. After a record is inserted, a user could insert another record with a changed values for any one of the 4 columns. Now, the question is how many prior id's do I need to maitain? and how could I retrieve all the records pertaining to a original transaction?

Thanks,

Rao

-----Original Message-----

Sent: Saturday, September 22, 2001 1:05 AM To: Multiple recipients of list ORACLE-L

Rao,

1. Since the primary key value(s) can change then it cannot be the primary key. You have to use a surrogate key. That solves that design rule.
2. When the user changes HP to IBM, why are you inserting a new record? Why cant you just update HP to IBM? If, for some reason, you have to insert a record, say the other values in the record change, then I would create a "PRIOR_ID" field, like someone else suggested, which would point to the "HP" record's ID. This field sould also be foreign keyed to the ID column.

Chris
"May Oracle be with you...always"

-----Original Message-----

Sent: Friday, September 21, 2001 4:58 PM To: Multiple recipients of list ORACLE-L

Christopher,

Thanks for the reply.

Surrogate key solves the problem of having a record with a unique identifier for a record. But I still have the following problems.

1. How do I link the previous records whenever a query is issued by the user?
2. Please see my requirement below:

Scenario:  

User inserts a record into transaction table. In the first record, Account ID value is "HP" and he might insert a record into the child table (Or this transaction may not insert a record into a child table). After some time, the user queries the original record with the primary key and then changes the value in the column - Account ID to "IBM". Now, the original transaction record is NOT UPDATED. A record IS INSERTED with the new values. Also, he might or might not insert a record into a child table with this new values of primary key.  

Now the user would query the transaction table with Account ID = IBM. But, the user wants to get all the previous records also; in this case, he want to see the record with Account ID = "HP" also. Also, he want to see the related records from the child tables.

How do I do this?

Thanks,

Rao

 -----Original Message-----
Sent: Friday, September 21, 2001 3:17 PM To: Multiple recipients of list ORACLE-L

Then use a surrogate key, i.e. sequence number.  

Numbers that change are not candidates for key, doing so introduces problems in which you are having as well as others. "Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes." Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275
Fuelspot
73 Princeton Street
North, Chelmsford 01863   

-----Original Message-----

Sent: Friday, September 21, 2001 2:30 PM To: Multiple recipients of list ORACLE-L  

In our case, we do not have any other columns --- 1. which could identify uniquely a record and yet do not undergo a change.  

Thanks,  

Rao
-----Original Message-----

Sent: Friday, September 21, 2001 1:35 PM To: Multiple recipients of list ORACLE-L Generally it is bad practice to use columns in the primary key, which change. They introduce many different problems.  

"Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes." Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275
Fuelspot
73 Princeton Street
North, Chelmsford 01863   

-----Original Message-----

Sent: Friday, September 21, 2001 12:35 PM To: Multiple recipients of list ORACLE-L  

List,  

OLTP application with 24x7 requirement. 300,000 records per day are inserted into the transaction table. Environment: Solari 7. Oracle 817.  

The transaction table layout.  

Security ID
Account ID
Account Type
Trade Date
And other columns in this table.  

In the above table, the primary key is -- Security ID + Account ID + Account Type + Trade Date  

There are many to one relationships built to other child tables from Transaction Table  

Scenario:  

User inserts a record into transaction table. In the first record, Account ID value is "HP" and he might insert a record into the child table (Or this transaction may not insert a record into a child table). After some time, the user queries the original record with the primary key and then changes the value in the column - Account ID to "IBM". Now, the original transaction record is NOT UPDATED. A record IS INSERTED with the new values. Also, he might or might not insert a record into a child table with this new values of primary key.  

Now the user would query the transaction table with Account ID = IBM. But, the user wants to get all the previous records also; in this case, he want to see the record with Account ID = "HP" also. Also, he want to see the related records from the child tables.  

I tried with the idea of sequence number generation but it was failing.  

Any ideas or suggestions are much appreciated.  

Thanks,  

Rao
Maheswara Rao,
Oracle DBA
SunGard Securities  

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rao, Maheswara
  INET: Maheswara.Rao_at_Sungardp3.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rao, Maheswara
  INET: Maheswara.Rao_at_Sungardp3.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).