In message
<[email protected]>, Baker
Hughes <[email protected]> writes
Very helpful Stuart (and Brian) thanks.
1 follow-up question: given your algorithm below, when you edit or copy
those records over, what does the key look like. E.g. do you have to
prefix the key generated by your algorithm, with the part file number
or name? To edit the record would you simply:
AE HAIRY.PF.NAME B123456
Or
AE HAIRY.PF.NAME 23-B123456 ?
Neither of these would work ... if you don't change the key, then the
record will not move file ... you'd have to do something like
AE HAIRY.PF.NAME B123456
SAVE 23-B123456
FD
I can't remember exactly what I did ages ago, but I remember that our
system wrote a sequential key when it created new records. The part-file
algorithm looked for a double-barrelled key - date-number - and if it
found the date it returned a date-specific part, otherwise it returned
0.
The archive routine selected part file 0, scanned it for records to
archive, checked that the date-specific partfile existed, then renamed
the record from "number" to "date-number" (in basic, it did a "read,
write, delete").
When working with part files, there are two things that you REALLY want
to avoid, unless you're prepared to give your users a fair bit of grief.
Either (a) changing the part algorithm, or (b) an algorithm that can
come up with a non-existent part in normal use.
We got round it by defaulting all records into part 0, and only moving
them elsewhere when we archived them. Another way would be for the part
number to grow sequentially, but MAKE SURE you always are on top of it,
or simply to make the original number of parts so large you don't think
you'll ever have to add any more :-)
Cheers,
Wol
74 & Clear regards from Ft Worth,
-Baker
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Boydell, Stuart
Sent: Wednesday, May 27, 2009 7:34 PM
To: [email protected]
Subject: RE: [U2] Best algorithm for UV part files
Well, it's a 'how long's a piece of string' type of question but we had
a requirement to archive old data from a heavily used file.
The file has several indices too many and is in use 24/7
This makes copy/delete a fairly heavy impact on the system and archiving
was always an issue.
The IDs in the file are a mix of numeric and prefixed keys eg 123456 or
B123456 from different systems.
We decided that a part file would solve the issue because you can remove
the part from the DF and because the indices are attached to the part
it's a very quick, clean action. If for some reason you need to put it
back - it's also very quick and easy.
So, we came up with a part file system which puts 100000 sequential IDs
into a part then moves onto the next one. For our requirement numeric
keys go in a different part from prefixed keys.
Theoretically this makes it easy to archive chunks of data by moving a
whole part and also to find specific date ranges for records based on
their keys within a particular part.
@PART.ALGORITHM = OCONV(@ID,'MCN':@VM:'MR05')[1] + 1;IF @ID MATCH '0N'
THEN @1 ELSE @1 + 10
Regards,
Stuart Boydell
-----Original Message-----
Does anyone have an opinion about the best algorithm to use for UV
distributed files?
The goal is ease of moving the records in the distributed files to other
files.
**********************************************************************
This email message and any files transmitted with it are confidential
and intended solely for the use of addressed recipient(s). If you have
received this communication in error, please reply to this e-mail to
notify the sender of its incorrect delivery and then delete it and your
reply. It is your responsibility to check this email and any
attachments for viruses and defects before opening or sending them on.
Spotless collects information about you to provide and market our
services. For information about use, disclosure and access, see our
privacy policy at http://www.spotless.com.au
Please consider our environment before printing this email.
**********************************************************************
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
This communication, its contents and any file attachments transmitted
with it are intended solely for the addressee(s) and may contain
confidential proprietary information.
Access by any other party without the express written permission of the
sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy,
distribute or use the contents, attachments or information in any way.
Please destroy it and contact the sender.
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
--
Anthony W. Youngman <[email protected]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
