Yesterday, I talked about some of the advantages of using IDs when working with various pieces of WordPress data and populating different input elements, saving it to the database, and more.
For certain types of data, this works well; however, this may not always be true especially as it relates to data types such as taxonomies. This is going to be most notable in WordPress 4.2.
If you’re an experienced developer, then I recommend reading the blog post linked above; otherwise, suffice it to say that using IDs may not always be the best option depending on if you’re doing a database migration (and how that migration might be done).
So what else are we left to do?
WordPress Meta Data: Another Use Case
Based on Helen’s tweet from yesterday (and the ensuing Twitter-conversation), I was going to write up a bit more of a technical example, but Shazdeh left a good comment on the post yesterday that captured the gist of the problem:
I think using “slugs” would be the better choice than IDs to save data. In case of taxonomies, post types and posts, WordPress generates the slug automatically and the good news is, after migration the slugs stay the same whereas IDs might change.
From a technical perspective, this still has us asking why we wouldn’t use IDs?
Whenever a record is created in a database, it receives a unique ID that’s used to identify that record within the context of that database instance. Many times, this ID is set to auto-increment from the previous value that was created.
But let’s say you end up deleting posts or moving other records around and, generally, the IDs and other pieces of information don’t out of sequence (or simply aren’t as reliable as before). Then say you need to migrate the database.
When the data is created in the new system, the IDs aren’t guaranteed to be the same. If you depend on that for consistency, then you may end up with something that doesn’t work.
Strategies For This Implementation
As with anything in programming, there are alternatives and options that we have for handling situations like this:
- Don’t Use IDs. Instead, use slugs or other forms of representation that are not going to be dependent on the database in which the information is written.
- Write a Migration Tool. If you’re already using IDs and you’re preparing to move a site or application from one system to another, then it’s possible to write a script to aid in the migration so that this doesn’t happen when the site is moved.
- Refactor Your Code. Sounds obvious, doesn’t it? But how many of us, whenever faced with a technical challenge, will end up skipping over one of the things that seems most obvious and instead focus on something that may be more complicated?
Does this mean that the content shared yesterday is irrelevant? Not at all. We’re all going to be faced with different challenges in the work that we do, and we’re all going to be faced with different implementations of our solutions.
The best thing that we can do is be prepared for whatever may come our way with respect to the functionality of the site. If what you have now works and there’s no plan to actually change the site or move it, you’re good. If not, then adopt one of the practices above.
Regardless, you have options and that’s one of the nicest things about programming.