Custom Post Type or Custom Tables

I am in the process of writing a plugin that allows end-users to submit a form that includes customer information. Upon submission, I am notified that a new customer has submitted the request form. If I approve the account, I am going to create a WordPress user account.

I am at the beginning stages of this plugin and want to know if I should use custom database tables to store my user information, or if I should go the route of just simply using a custom post type and adding meta-data to the post type?

Read More

UPDATE:

Wow, down-vote already! Anyway, an update to my question, let me word it this way…I have now attempted to create a custom post type of customer, and for customer, I wanted to only have a meta-box that contained First Name and Last Name. When I did this and disabled all of the supports options for the custom post type, it was a nightmare listing the posts due to the missing Title value. It would always set the Title to “Auto-Generated” and that doesn’t work for me. I ran into this GREAT Plugin (super-cpt) that makes the creation of custom post types and meta-boxes a breeze.

So, I’m not so sure custom post types will work for me since so much custom UI work needs to be done to convince the front-end and admin dashboard to work for me. I’m leaning more and more on custom data tables but would like more info on customizing the edit form for a custom post type. Anyone have a link they could share?

Related posts

Leave a Reply

2 comments

  1. I don’t know if we are allowed to link to other answers but there is another question very similar to yours and the accepted answerer stated these things:

    You should be skeptical of anyone who says that there is a single
    “right” way. The right way depends on the situation. Using the CPT
    infrastructure has a number of notable benefits:

    • You get the Dashboard UI for free
    • You automatically take advantage of WP’s caching, including any persistent cache plugins that the installation may be using
    • You automatically get goodies like post revisions
    • You get access to the WP_Query class, which means that, in theory, you don’t have to write any (or at least not much)
      likely-to-be-buggy-and-vulnerable-and-inefficient SQL

    If you’re planning on distributing the plugin or opening it up for
    open-source development, you may find that developers are more
    comfortable using custom post types and the associated API functions
    than your own custom stuff.

    source: Here

  2. If there is more than 1-2 meta related to your custom post type, the possibility (or necessity) of complex user searches based on that custom data, then custom table. Otherwise complex JOINs done on meta tables to pull posts by querying 2-3 criterion at the same time on meta table will slow the site down. Considerably, based on concurrent users. If you have ~5,000-10,000 such data entries, you will enter a query hell.

    If around 1-2 meta, OR, there wont be complex user searches for your meta data, and the data does not need to be displayed dynamically (can be cached without loss of user experience), then go with WP’s post and postmeta.

    Incidentally you can also do something quite out of the way, you can create a custom table to mirror all your post entries with its complex meta data in a flat, relational table and hook to search function (or other necessary functions) to do the search from this custom ‘search cache table’ and then go read the result set from wp_posts and wp_postmeta, you can go with wp tables for massive complex data sets as well. But then you will need to divert any problematic query operation to this cache table of yours.

    I believe popular search plugin Relevanssi does something like that – cache complex post and postmetas in a flat, relational table and pull out search results from there.

    *correction – incorrect: relevanssi does not create a datastore for faster search. It just improves the search quality.

    But really, that’s going too out of the way in my opinion. Just go with separate tables if your data is big and complex.