Wordpress - Is it bad practice to create own table for a plugin?
I rarely disagree with otherwise knowledgeable users, but in this case I can't help it. In my opinion calling the usage of non-core database tables bad practice per se is just simply wrong.
The choice of whether to go with core tables or add your own depends on several factors.
A query's execution time depends on the size of the table. Hence, if you're planning on storing significant amounts of data, a separate table catering to just this one type of specific data set will inevitably be the more efficient solution.
If you store a lot of regular posts or CPTs alongside these specific data sets, wp_posts as well as wp_postmeta can grow quickly.
For me, this choice ultimately depends on how "posty" the data is. Should it support an author, comments, revisions, excerpts or the like? If so, I'll go with CPTs and/or core functionality. If not, I'll go with separate tables for the sake of resource usage and efficiency.
If Eugene's notion were correct, none of the existing well-written plugins would add their own tables, which fortunately is not the case.
Using WP core DB tables is best practice
- Using core DB tables makes your data more portable, and easier to backup, since it will be handled by the core exporter/importer, as well as by the myriad backup Plugins
- Using core DB tables makes your data easier and safer to manipulate, since you will have more intuitive access to the various WordPress core functions related to querying, adding, modifying, deleting, and sanitizing DB data, particularly through the very powerful
$wpdbclass. - Using core DB tables encourages/facilitates best practices for data classification and storage, such as storing Plugin options as an array in a single row in
wp_options, and by forcing the Plugin developer to consider carefully the type of data being created/stored - is it a CPT? is it a taxonomy? is it post meta? - Your Plugin is less likely to leave behind cruft when using core DB tables.
WordPress provides a means for Plugins to add tables to its database
However, for those use cases where a separate DB table is needed, be sure to use the method that WordPress provides for adding your custom table to the WordPress database, especially so that you can take advantage of the powerful $wpdb class. Note the information/caveats this Codex entry lists:
Setup information -- user choices that are entered when the user first sets up your plugin, and don't tend to grow much beyond that (for example, in a tag-related plugin, the user's choices regarding the format of the tag cloud in the sidebar). Setup information will generally be stored using the WordPress options mechanism.
Data -- information that is added as the user continues to use your plugin, which is generally expanded information related to posts, categories, uploads, and other WordPress components (for example, in a statistics-related plugin, the various page views, referrers, and other statistics associated with each post on your site). Data can be stored in a separate MySQL table, which will have to be created. Before jumping in with a whole new table, however, consider if storing your plugin's data in WordPress' Post Meta (a.k.a. Custom Fields) would work. Post Meta is the preferred method; use it when possible/practical.
Thus, we can conclude the following:
- Storing data (setup, or user-generated) in core WP tables is best practice
- There are valid use-cases for creating custom DB tables; therefore, creating custom DB tables cannot be considered as an inherent bad practice
- When creating custom DB tables, WordPress provides a best-practice implementation