On 7/22/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 22 Jul 2006, at 21:35, Matt Westgate wrote:
Other CMS's have been improving their URL alias feature by storing each alias with the data it represents. We could store node aliases in the node table, user aliases in the user table and menu aliases in the menu table. This reduces the amount of queries we need to generate and would avoid an alias-specific caching solution.
Of course there are other rogue aliases that couldn't be accounted for with this approach, but I bet we'd reduce the number of alias queries by 80%.
That's easy to count. Just add some counter logic to drupal_lookup_path() and we'd be able to estimate the gain. :)
Anyway, this brings us back to the de-normalization discussion we've had lately. We could potentially cache a lot of node related properties in the node table (eg. the comment count, last comment timestamp, username, etc).
We're running around in circles, me thinks. Time to implement some approaches and to compare their implementation and performance?
Matt has a point here ... I don't think it is bad denormalization in this case. What we have now is a one to many relationship of node -> alias, and we allow multiple aliases for the same node. If we go to a 1:1 relationship, then the logical place for the alias is in the object that it represents (term, user, node), and this would speed up things for certain operations (e.g. emitting an alias instead of the native path), but potentially slow others (looking up an incoming alias and converting to the native path?) What we lose here is the ability for multiple aliases. Or we can keep the other (older/additional/...etc) aliases where they are now, and have the current alias in the object's table. To clarify: I have node/123 which starts life as this_is_an_alias, based on what pathauto does. This is indexed, linked to, ...etc. Then later, the title changes, and it becomes this_is_a_new_alias. this_is_a_new_alias is stored in the node table, and this_is_an_alias is in the url_alias table. The same goes for a user who calls himself kbahey then decides to change his Drupal name to KhalidB. This is not bad denormalization if it can be called that. The current alias represents something and the older one represent something else. If there is an index on the current alias field, it will take care of the slowness part to some extent.