What's wrong with using something like the Nested Tree Model?
That requires minimal joins, so the key size shouldn't be a big factor in the overall performance.
or did I miss something?
Spike
Matt Liotta wrote:
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).
----------------------------------------------------------
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).
