There’s not really much reason to have posts in their own table. You perceive it as cluttering the table, but mySQL knows where everything is and can quickly find anything, so from the DB point of view, it’s not cluttered. Adding extraneous tables is cluttering things from that view.
It’s your choice of course. If I were to implement a separate table, I would keep it completely separate from WP posts. I would still use some WP functions and classes to integrate my post type into the backend, but all DB related actions would be via generic $wpdb methods, not specific WP functions, nor WP_Query.
I would however, use the Settings API to integrate my backend pages into the rest of the admin panels. I would also use WP_List_Table to display the table elements, and meta boxes for the various fields. Thus, the post type appears fully integrated like any custom post type, but the underlying code handling things would be my own.
TBH, this all sounds like reinventing the wheel for the sake of a misguided sense of order, but that’s your choice. I apologize for being blunt, I intend no malice. I also know I do not have all the reasoning behind your scheme. I actually don’t care what you do, but what ever you decide, I wish your decision to be an informed one, and I will try to help you if I can no matter what. Cheers.
I think I see where you’re coming from… What I’m trying to do is basically create a directory of sorts. Something like Yelp, for example. I would need to have a custom post type (called Listings or Places) perhaps. I don’t mind creating my own functions, queries, etc, though I’d rather keep it as true to wordpress as possible. My problem with this is that with it’s own table, each “Listing” won’t have it’s own page (basically a single post under single.php). This is why I was leaning towards using the default wp_posts table and possibly the post_meta table as well to store information about the listing. I’ll try going about it with the default wp_posts way and see how it goes. Thanks for the advice.
