I see no problem in realizing it in WordPress itself. WordPress also has its own caches for this data, which could speed up reading. With a separate database table, you only have this to a minimum.
@threadi Thanks for the reply. It can definitely be done using the WP posts functionality, but is it worth the extra time it would take, given that the data refreshes so frequently? Each of the pages I want to make on the fly is a call for basically one row from a table (and one call to write the data for each page, when the data comes in from the external source). I would think going to a table for one row would be so much faster than doing the work of creating/calling a post object … or is it? I can see advantages to having a post, but my concern is that the extra processing of creating and reading them would negate any benefits.
I don’t see much difference in inserting or updating a post vs. inserting or updating a row in a custom table. It’s essentially the same process either way. If you had a custom post type with no associated taxonomies, that would eliminate any taxonomy table queries. Where there could be a difference is in any post meta you might need. The WP post meta schema is very accommodating, but not terribly efficient. Inserting or updating post meta isn’t the problem, it’s in search queries that involve criteria in post meta. If you need to make frequent search queries involving post meta in a very large data set, you’d likely see better performance if the meta data used as search criteria were in a custom table. Post data itself and meta data not needed for search criteria can still be in standard WP tables. There’s little to be gained by having such data in custom tables. IMHO of course.
