Hello, Op dinsdag 25 juli 2006 16:53, schreef Khalid B:
Easy, we'd continue to maintain a URL alias table with all the path aliases. In the node/user/taxonomy object we'd just 'cache' the active path alias (duplication).
(I'm not claiming this is the best solution.)
Sounds like a legitimate case for de-normalization for performance. The tricky part is making sure that who ever updates one updates the other, so we stay consistent. This better be a function that is called and does the work behind the scene, and no one touches the raw tables.
It is not persé. The problem is far simpler, and IMO we are circling around the wrong solution all the time: fact: a lot of db queris (in a huge table) has bad performance. fact: anything that is created automatically can be de-created automatically. fact: with a very few exceptions everyone with large alias tables is using pautauto or another automated method. example: node/123 -> posts/news/man-falls-in-water which was generated with a "pattern" posts/[term_name]/[title] why do you want to store that in the first place? It is just as simple to tear apart then to mak. It is not even a heavy piece that yuo might want to cache. IMO we should look beyond the "path table is slow, let us make the table faster". A few other concepts to look at are: * routers: menus not only handle incoming links but the outgoing ones too. (detail:http://lists.drupal.org/archives/development/2006-05/msg00864.html ) * hook_alias (with caching, quit-after-first-hit and other speed optimisations): pathauto can deliver a on-the-fly-crafted link. path.module can deliver aliases from the DB * callbacks: simple version of routers: each path *pattern* gets a callback function that will handle the (de)composing of that path. I guess there are a lot moer options, options that have more potential in performance, flexibility and simplicity of code then just tweaking the path tables. Bèr