Re: [CFCDev] Structs in a CFC not Quick enough?? (possible bug?)

[Matt Liotta]

I think you are looking at the problem from a database perspective as 
certainly 32 bytes is relatively small in database terms. However, a 
taxonomy is a tree, not a table, so you have to think about the problem 
differently. A tree has hierarchical semantics that are sometimes 
important to capture. Thus, if you actually represent a tree in a 
database then you have to rebuild to tree before you can query it 
effectively. At that point, doing recursive joins on 32 byte keys 
starts to add up and your database starts to slow way down. Being able 
to represent the same tree with say 4 byte keys makes an enormous 
difference.

Anyone who doesn't think so either knows something I don't or they 
simply haven't built large trees before. And BTW, most simply 
taxonomies grow to be large trees over time due how hard classification 
actually is.

-Matt

On Tuesday, June 17, 2003, at 05:43 PM, Adam Cameron wrote:

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).
----------------------------------------------------------
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).