@ahockley,
Actually there are a number of threads on this forum that have developers asking exactly how to use custom post types with a custom table because of obvious scalability issues for sites with hundreds of thousands of rows of data. Most of them have been closed, but never answered. Do you really want to slow down the entire post-based site by cramming a half million, or a million, or ten million rows into it? For the average customers sitting on GoDaddy with no knowledge of memcache? That's the average plugin customer today.
The $wpdb codex article doesn't cover it, neither does the how to create plugin tables article.
We should keep that in mind when we ram a bazillion rows into their primary database table that the entire site uses, don't you think that's an obviously wise way to avoid the risk altogether? Lots of people have scale issues over 400-500k posts in the DB, the plugin we offer has the potential to create that many on any successful site, certaintly given years to do it.
So why are there 10 closed threads on the topic and no good docs in the Codex for using Custom Post Types with your own custom table? Maybe it's just buried but all the people asking for YEARS haven't really been answered well. Why does Stack Overflow manage to have better insight on this than the Codex docs site? Now that WP is an extendable platform, it's a pretty perfect question for anyone considering using it as the base framework. I'm tired of reading "oh nobody does that" or "databases can't be too big, hardware can only be too small" - yeah no kidding, this is WORDPRESS we're talking about, it's installed millions of times on shared hosting!
Let's keep things quick and snappy, and humor the lunatic engineers on these forums who are just trying to think ahead a bit. Let's not encourage the only design is to bloat the system with every plugin ever's data.
So the Question to the senior experienced support forum contributors and moderators is:
What's the best way to do it, officially?