Database pulls aren't so expensive when you're doing them properly, and you have indexes on the fields in question. Indexes get lookups down to O(1+k/n), which is much faster than linear.. DB writes are the expensive operation (and even more so if the tables are indexed). But there are other tricks to speeding up data retrieval, like caching in memory as well.
Here's the thing. If Laconic is just for joking, I'm not sure if importing the pages is even worth it. This might be one of those "and nothing of value was lost" choices. Some of them are good summaries, most of them are passable summaries, and some of them are jokes, and a few are even good jokes. So what is it supposed to be?
VOTE
Given that the software will have a summary field, Laconic pages won't be needed for descriptive power. I see a few options here:
A1. Import the Laconic namespace as subpages, and use it for one-liner jokes. All summaries will start as autogenerated at first, and all pages will be tagged with 'needs_summary'.
A2. Use the existing Laconic entries as summaries where available, and tag all other pages with 'needs_summary'. Don't import Laconic as pages.
A3. As A2, but tag every page with 'needs_summary', so the laconic ones will be rewritten too.
A4. As A3, but go ahead and import the Laconic pages to subpages, too (so they'll be on both Page/Laconic and Page's summary).
A5. Don't import Laconic, autogenerate all page summaries, tag all pages 'needs_summary' (option Nuke Laconic from Orbit)
Again, in this context, "autogenerate" means "let the software take the first two lines of the article as a stand-in summary, until someone fills out the blank summary field". Also note that there are 11,302 laconic pages, which means ~1/15 of entries have a laconic -- the majority will be autogenerated in any case. And each option takes roughly the same amount of time to implement in the importer, so that's not an issue.
As for me, I'm leaning A3, and somewhat against A1 for now. But I'd like everyone else to vote or offer an opinion.
-- ∇×V
Here's the thing. If Laconic is just for joking, I'm not sure if importing the pages is even worth it. This might be one of those "and nothing of value was lost" choices. Some of them are good summaries, most of them are passable summaries, and some of them are jokes, and a few are even good jokes. So what is it supposed to be?
VOTE
Given that the software will have a summary field, Laconic pages won't be needed for descriptive power. I see a few options here:
A1. Import the Laconic namespace as subpages, and use it for one-liner jokes. All summaries will start as autogenerated at first, and all pages will be tagged with 'needs_summary'.
A2. Use the existing Laconic entries as summaries where available, and tag all other pages with 'needs_summary'. Don't import Laconic as pages.
A3. As A2, but tag every page with 'needs_summary', so the laconic ones will be rewritten too.
A4. As A3, but go ahead and import the Laconic pages to subpages, too (so they'll be on both Page/Laconic and Page's summary).
A5. Don't import Laconic, autogenerate all page summaries, tag all pages 'needs_summary' (option Nuke Laconic from Orbit)
Again, in this context, "autogenerate" means "let the software take the first two lines of the article as a stand-in summary, until someone fills out the blank summary field". Also note that there are 11,302 laconic pages, which means ~1/15 of entries have a laconic -- the majority will be autogenerated in any case. And each option takes roughly the same amount of time to implement in the importer, so that's not an issue.
As for me, I'm leaning A3, and somewhat against A1 for now. But I'd like everyone else to vote or offer an opinion.
-- ∇×V