At 03:22 PM 1/21/2003 -0700, F. Alfredo Rego wrote:
>At 1:28 PM -0800 1/21/03, John Clogg wrote:
>
>>Another issue with abandoning the absolute record number requirement,
>>besides performance, is how to accurately identify the record to be updated.
>>If the search item is not unique, which is often the case on Image details,
>>how do you make the choice? There might be other items in the record that
>>could be used to distinguish a unique member of the chain, but that would
>>require some knowledge of the application, which would have to be
>>configurable in the shadowing product. Another means would be to compare
>>the entire record. Arguably, Image does not disallow duplication of even
>>the entire record, but in that case does it really matter if you update the
>>"wrong" one? It's an interesting problem. In either case, you would need
>>to read down the chain looking for the right record. It could be pretty
>>costly in some databases! You would need to consider shadowing performance
>>in the design of your database.
>
>
>I also received a private message on the subject:
>
>>Surely it MUST work this way based on the current limitations of Image. Since
>>Image does not allow for a unique search item in a detail dataset, the only
>>100% absolute way to identify an entry is by its relative record number. You
>>can argue that it is a poor application decision to allow two completely
>>identical detail records to be placed into the database, but there is nothing
>>in Image to stop it. Hence, the shadowing products use this for both
>>performance and for data integrity. BTW, this is also how DBRECOV
>>operates. If
>>you play a log file back into a database the detail updates are based on
>>record number.
>
>
>These two independent sources imply that great minds think alike! I would
>like to thank both colleagues for their well-reasoned essays.
>
>With the benefit of these timely reminders, I would also like to update
>my original post:
>
>> > This is a question for the shadowing folks, having to do with
>> > performance (most likely).
>
>In addition to "performance", please include the comments from my two
>colleagues.
>
>
>> > "Depending on absolute entry numbers" can
>>> be one of the prices that they choose to pay to obtain performance.
>
>Given the issues mentioned by my two colleagues, the shadowing folks did
>NOT have any other choice. They HAD to depend on absolute entry numbers.
>
>
>> > If such is the case, then it is certainly not possible to keep the
>>> master and the shadow repacked under different path criteria, because
>>> that would confuse the shadowing software's dependence on absolute
>>> entry numbers.
Our Backchat product will support this, I assumed that everyone else would
also. The problem, in our case, is that when we do a check for a matching
"before" record and find a difference, then we go to our cross reference
database that we maintain to see if that relative record has an xref
entry. This obviously involves more overhead but it has always impressed
me how well it actually does work. Hard to beat TurboImage.
>This is so under any circumstances, regardless of the reason for the
>dependence that shadowing software has on absolute entry numbers.
>
>The search for creative solution(s) to Eben's challenge continues!
>
> _______________
> | |
> | |
> | r | Alfredo [log in to unmask]
> | e | http://www.adager.com
> | g | F. Alfredo Rego
> | a | Manager, R & D Labs
> | d | Adager Corporation
> | A | Sun Valley, Idaho 83353-3000 U.S.A.
> | |
> |_______________|
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
Brian Duncombe [log in to unmask] http://www.triolet.com
voice: 1-877-TRIOLET (874-6538) (905)632-2773 fax: (905) 632-8704
"Inside every large program is a small one desperately trying to get out"
C.A.R. Hoare
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
