|
General Q/A
< Previous Next >
re: Suggestion: mountains of IDs
John Greenan / Alignment Systems
29 Apr 2004 4:58AM ET I'd like to add a couple of points to the ideas raised. First, I agree that walking a tree (find order A, then find the order id that it replaces, then find that replaced order, find the order id it replaces...and so on) to find the complete history of an order is an unwelcome chore when supporting FIX.
By adding a repeating group of every order id this would be helpful in that you can immediately get to the nth order by looking for the nth member of the repeating group.
I'd modify this proposal slightly by adding in a new datatype of uniqueidentifier which would then be used in as for the order id. The benefit of this is that by having genuinely unique order ids across sessions, clients, engines, days (whatever) the process of searching databases and log files for order ids would be much simpler. The order id would then be generated using a standard tool (such as CoCreateGuid in the windows OLE32.DLL).
This would make order ids not human readable (such as 32EEAEE2F42248de85E71185926C9E0B) but genuinely unique, without requiring any centralisation of order id assignment.
For more about how/what a guid is have a look at www.dsps.net/uuid.html or http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt
re: Suggestion: mountains of IDs
John Greenan / Alignment Systems 29 Apr 2004 4:58AM ET
|
