In the last month or two, I’ve begun writing some simple plugins for WordPress and I’ve been a little frustrated by one of the application/database design decisions which have been made.
Most web sites consist predominantly of read activity and infrequent write activity. As such, it is in the interest of performance that, where applicable, you store an aggregate value instead of calculating it. This design decision was made correctly by storing the number of comments per post in the wp_posts
table. Unfortunately, this technique has not been used for storing the URL for a post. For whatever reason, to get the URL for a particular post you need to call get_permalink()
– which through the use of a few other queries derives the URL for the page.
I can understand to some extent why this was done, it makes sure that the URL presented for a post is always the current one. I think the other reason might involve creating a convenient templating language for the public to use with WordPress. As a simple example, consider the lists of posts you see on this site. Instead of requiring a single query to generate these lists, it requires n+1 queries to generate the lists where n is the number of posts you want displayed.
What I don’t understand is why the guid
field in the wp_posts
table isn’t updated and kept in sync with the post and a users desired permalink structure. Employing a simple mechanism like this would mean generating a list of URL’s would only issue a single query. If this was the case, you’d end up with a scenario where:
- drafting a post would create a permalink
- publishing a post would update the permalink
- changing the publishing date of a post would regenerate the permalink
- changing the permalink structure would regenerate all permalinks
One other thing which is a little frustrating is that after asking in #wordpress on irc.freenode.net, no one at the time could clarify what the guid
field was used for and why it isn’t kept in sync as pointed out above (maybe its a bug?). The other thing which I couldn’t find on the codex, was a good definition of all fields in all tables and what they logically represent. If I happen to run into Matt or Ryan, I’ll be sure to ask them to confirm one way or the other.