What I should have said is that the structure prevents locking issues in very high volume sites thus ensuring performance is not degraded unnecessarily.
High volume site here refers to many millions of transactions per day. The structure also allows similar records to be netted together, in order to do this the ID needs to contain the characteristics so that an existing summary record can be read and updated; remember that the summary records will be updated intermitently as transactions occur throughout the day. I guess there is also a benefit for issue diagnosis as the main files will contain less entries and selects would be faster (but still not fast) then once the offending summary record is found the XREF record can be QSELECTed to obtain the DETAIL IDs. On May 6, 4:53 pm, Vlad <[email protected]> wrote: > IMO 'ugly' structure does not ensure performance. It's all about the > number of transactions, and netted postings are a kind of solution. > But record ID of netted posting with a length of 108 characters can't > be considered a smart design. They could generate netted postings with > smaller ID structure, let say BOOKING.DATE*KEY.AND.TYPE*TR.CODE (or > even the same as detailed RCSE with just one extra flag in the body of > the record saying this is a netted posting). > > Indeed, the unconsolidated version of the ID is meaningless. But I'm > wondering how 108 size ID of the netted posting will help you > investigate RCSE issues, since any selection on STMT.ENTRY, > CATEG.ENTRY or RCSE usually takes hours to finish (I mean on serious > databases, not on Temenos HD model bank with two customers and three > accounts)? OK, may be It would be somewhat helpful to select XREF > files. > > On May 5, 10:02 am, John Watson <[email protected]> wrote: > > > > > I have as many problems with T24 design as everyone else but the > > 'ugly' structure ensures performance in exceptionally high transaction > > volume sites. > > > The key is designed to give a good distribution for transactions > > whilst ensuring commonality (each component is a transaction > > characteristic) and minimal locking; the use of these consolidated > > entries reduces the COB time by ensuring fewer records have to be > > processed. > > > The unconsolidated version of the ID is simply day / port / time / > > sequence so is equally meaningless for investigation purposes. > > > John. > > > On Apr 24, 4:26 pm, Vlad <[email protected]> wrote: > > > > I'm wondering who invented those netted postings. Probably it was > > > really a bad day for those who decided to make such an ugly structure > > > of the ID. Instead of standard "150810001139384.00" style, now > > > RE.CONSOL.SPEC.ENTRY file has this "R!LD.1.TR.BHD.21071.1002.BH.5Y.... > > > 1200.3..17.LIVEDB.20100308!DR!BHD!LD!CNW!20090308!!!1!!!20090308!17! > > > 21071". Obviously, Temenos has to hire some good architects.- Hide quoted > > > text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
