>A UUID scheme would require a UUID for the node as well as a UUID for the parent which is quite a bit of data.
32 bytes in the database (16 apiece) is hardly "quite a bit of data". A UUID is a 128-bit number (you mention this), which is *presented* to you or I as a 32-char (with some additional hyphens) string. The DB stores it as a 128-bit number (go have a look at the "length" param of a uniqueidentier field in an MS-SQL DB: 16 (128 bit)). >However, Microsoft's original UUID implementation, which they submitted to the IETF and it became the specification represents a UUID using a 36 character string. *Shurely* that's *just* the human-interface output, whereas the data is stored as binary. So where's the problem? > Further, most of the industry represents UUIDs this way as well. Of course, the UUID string that CF generates is 35 characters in length, so it doesn't follow the norm; it is different by a hyphen specifically. I never quite worked out why any platform bungs a bunch of hyphens in there (especially if the're not treated transparently by any processing). And I'm more puzzled as to why Allaire decided to use a UUID format that cannot be inserted into a MS-SQL DB without reformatting first! Dorks. I'm a firm believer in keys (esp in this situation) holding meaningless data (my co-worker will be smirking as he reads this... I made this very statement in a conversation about this thread last night). I also wonder about your idea of the key data representing the positioning in the tree... If you move that node to somewhere else in the tree, don't you have to change your key data? EEEEEEEEEEEEEEEK. Adam ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
