Why is this custom taxonomy showing in the database?

Question

I have created a plugin that add geographic data to Wordpress. According to this answer the taxonomy data should not be stored in the database, however it seems to be stored:

mysql> select * from wp_term_taxonomy where taxonomy='geoareas' limit 10;
+------------------+---------+----------+-------------+--------+-------+
| term_taxonomy_id | term_id | taxonomy | description | parent | count |
+------------------+---------+----------+-------------+--------+-------+
|              953 |     699 | geoareas |             |      0 |     2 |
|              954 |     700 | geoareas |             |    699 |     0 |
|              955 |     701 | geoareas |             |    700 |     0 |
|              956 |     702 | geoareas |             |    700 |     0 |
|              957 |     703 | geoareas |             |    700 |     0 |
|              958 |     704 | geoareas |             |    700 |     0 |
|              959 |     705 | geoareas |             |    700 |     0 |
|              960 |     706 | geoareas |             |    700 |     0 |
|              961 |     707 | geoareas |             |    700 |     0 |
|              962 |     708 | geoareas |             |    700 |     0 |
+------------------+---------+----------+-------------+--------+-------+
10 rows in set (0.00 sec)

Why is that data stored in the database? And what would be the proper way to remove the data on register_deactivation_hook since wp_delete_term() seems to only remove the terms and not the entire taxonomy from the database. Do I manually need to remove all Term-Post and Term-CustomPostType associations in the database, and then all references to the taxonomy itself? Or is there an internal WP function that I should be using? The obvious wp_delete_taxonomy() does not exist!

EDIT: It seems to me that all the taxonomy data storded in the database is stored in the wp_term_taxonomy, wp_terms, and wp_term_relationships tables. Would these three queries be sufficient to purge the taxonomy data from the database on register_deactivation_hook()?

DELETE tr FROM wp_term_taxonomy tt INNER JOIN wp_term_relationships tr ON tt.term_taxonomy_id=tr.term_taxonomy_id WHERE taxonomy='geoareas';

DELETE tt FROM wp_term_taxonomy tt INNER JOIN wp_terms t ON tt.term_id=t.term_id WHERE taxonomy='geoareas';

DELETE FROM wp_term_taxonomy WHERE taxonomy='geoareas';

Answer 1

Taxonomy "data" is indeed stored in the database. Taxonomy "definitions" are not.

The stuff you put into a call to register_taxonomy is not the data, it's the definition of that data. Stuff you add, like categories or tags, is the data, and yes, it goes in the taxonomy tables like any other taxonomy data.

You need to call register_taxonomy every time so that WordPress knows the taxonomy exists and how to deal with it. The data from the taxonomy comes from the database. Your definition of the taxonomy comes from the code.

Additional:

The question of how you should delete data entered by the user actually is more complex than just the technical means. All the means you mention work, but the real question is whether or not you should delete that data. Maybe the user put a lot of hard work into defining those geoareas themselves. If they remove and reinstall your plugin and the data is now just vanished forever, then that's kind of a terrible thing.

Also, you absolutely should not remove such data on register_deactivation_hook, because people can deactivative and reactivate a plugin easily. If you were going to remove data, it would be on an uninstall.php file in the plugin (which, unsurprisingly, only runs on an actual uninstall of the plugin, and not mere deactivation). A better approach might simply be to provide the user with a "wipe all the data" button instead. Put control of their data into their own hands.

If the data in question is unchanging and created automatically somehow, then regenerating it after a fresh install might make sense, but that's pretty rarely the case for taxonomies. Might want to reconsider your overall strategy instead.