On 7/23/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Saturday 22 July 2006 16:19, Khalid B wrote:
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.
I don't see how we do. It just declares one alias "primary".
That is, if node 5 has an alias of my/fifth/node in the node table, that is the alias that is used for any output. Vis, system-generated links to node/5 are always rewritten to my/fifth/node.
The separate alias table then is for *incoming* paths. You can have as many aliases for a page as you want for incoming requests, but only one for Drupal output. (And really, why would you want to have multiple aliases that get printed by Drupal? That only confuses people.)
As an example, suppose you have a weekly newsletter, with each newsletter being a node. The alias for each newsletter would be its date, say newsletter/2006-07-22. That's the primary alias, and that's in the node table. Then there's also an alias newsletter/latest that points to whichever is most recent (updated however), which you can put into mailings and such. Once the user's there, however, there's no reason to not send them to the dated alias.
So we're not losing multi-alias support at all, at least not really.
You are right. I sort of negated that in my previous message when I said: "Or we can keep the other (older/additional/...etc) aliases where they are now, and have the current alias in the object's table.", and the example says that. So, I am in support of the main/current/primary alias being in the node table and the others where they are today for incoming requests. That should improve page generation for taxonomy, node and users, since there will be zero extra queries.