 Hey there, and welcome to Learn WordPress. In this tutorial, you'll be learning about creating custom database tables for WordPress. You will learn where to find information about creating custom database tables, how to create custom database tables, and how to interact with them. The default WordPress database schema is typically enough for all content types. The ability to register custom post types and use post meta usually covers most options. However, in some cases, you may need to store data that doesn't fit the default schema. For example, in an e-commerce store, a custom post type would work for products, as it has similar fields to a post, for example, a title, image, and content. Any additional fields it might need can be stored as post meta. However, an order does not use the same fields as a post, and therefore it might be useful to store orders in a custom table. For the occasions where you need to store data that doesn't fit into the default schema, you can create your own custom database tables. While WordPress developer documentation does not include anything around custom database tables, there is an older version of the developer documentation called the Codex that does. You can find everything you need to know about custom database tables in the creating tables with plugins page on the Codex. The first thing you'll notice is that this is typically done in a plugin. Additionally, it is possible and recommended to create custom tables when the plugin is activated using the register activation hook function. This allows this functionality to be run once, and not every time the plugin is loaded. To create a custom table, you need a few things. To start, you need a function to manage the table creation. Then you need to use the WPDB global, as it contains all the methods you need to interact with the database. This will allow you to set up the new table name using the WordPress database prefix. It will also allow you to access the get char set collate method, which will return the correct character set and collation for the database. To create the table, you need to know SQL to execute an SQL statement on the database. This is done via the DBDelta function. DBDelta is a function that is generally used during WordPress updates. If default WordPress tables need to be updated or changed. It examines the current table structure, compares it to the desired table structure, and either adds or modifies the table as necessary. You can read more about these requirements in the creating or updating the table section of the codex page. Once you've created the SQL statement, you need to pass it to the DBDelta function. This is done by including the wp-admin includes upgrade.php file, which contains the function declaration. In this example, a new table is being created called custom table. It has five fields, an ID, time, name, text, and URL. The ID is an auto incrementing integer and the primary key on the table. Hocking this function into your plugin activation hook will ensure that the table is created when the plugin is activated. It is also possible to use the plugin activation hook to insert data into your table on plugin activation. To do this, you can use the insert method of the WPDB object, passing an array of field names and values to insert. Here is an example of what this could look like. To update data in your custom table, use the update method of the WPDB object, passing in an array of field names and values to be updated, as well as an array of field names and values to use to find the record to update. In this example, the record with the ID of one will be updated with the new values. Selecting your data from your custom table is done using the get results method of the WPDB object. Get results will accept a valid select SQL statement. By default, get results will return an array of objects which you can loop through and access the row fields as properties. It's also possible to delete your custom tables. To do this, you can use the query method of the WPDB object, passing a SQL statement to delete or drop the table. The query method will run any valid SQL query, but it's best to only use it for queries that don't insert or update data, as this function does not perform any query sanitization. Depending on your requirements or the requirements of your plugin users, you could delete the table in two ways. If the users of your plugin do not need the data in this table if they deactivate the plugin, you could trigger deletion on the plugin deactivation hook. However, if the data in that table is important and your users might want to keep, even if the plugin is deactivated, you could delete the table using one of the two uninstall methods available to plugins. You can either use the register uninstall hook or the uninstall.php file. Alternatively, you could just leave the table intact and let your users decide what to do with it. It's generally recommended to check with your user whether they want to keep the table or not when the plugin is uninstalled and then use one of the uninstallation methods. This tutorial only scratches the surface of what's possible with custom tables. In a future tutorial, you'll learn how to implement this in a real world project. Happy coding.