[thesite] Community News Category

[rudy]

> if only we'd used variables in those queries
> and stored that list in a single spot.
> f*cking hindsight

hey, nobody can do everything perfect the first time

(especially me)

hmmmm...  time to revisit the idea of a flag on the categorys record?

hey, there already *is* a flag on the categorys -- the foreign key to
cattype

right now, all the existing categories are connected to the cattype
"Center"

personally, i see no harm in having several kinds of these things, and i'm
not the rigid stickler for "doing it the right way" as some data architects
you may have run across -- i'm way more pragmatic

CAUTION:  as long as the different types of categories are MUTUALLY
EXCLUSIVE

michele mentioned "... Community News will be treated in the same manner as
FAQ articles are, except that it will appear on the front page and it will
appear from the drop down box.  But, the queries wrt highest rated
articles, those impacting other articles by this author, and even article
revival will have special circumstances for this new category."

see, that's the problem -- those are all separate attributes, and if
they're not mutually exclusive, then overlap will occur and you can stop
reading right here

anyhow, i was thinking we could have one cattype called "Center" (for lack
of a better name) and another cattype called "Center that isn't really a
Center because it's not visible on the home page" and "Center that also
isn't really a Center because it's also not shown on the front page *but*
the articles are counted as written"

as long as they're mutually exclusive, this will work

obviously, we would want to do whatever we can to keep the number of
category types to a minimum

but with this method, we won't constantly have to add to the list of
categoryids to check, since this could get awfully complicated, as jeff
will surely agree, when it comes to testing categoryids in the various
different queries for different purposes -- instead, just check for the
cattypeid

note the join to the cattype table is not necessary, just check the
cattypeid in the categorys table

makes sense?

an alternative is to have a multitude of flags on the categorys record

and let me, before y'all explore that too much, mention that flags are just
crippled foreign keys

by collapsing multiple flags into one foreign key *which already exists*
and making the parent cattypes mutually exclusive, we can implement the
change now, rather than slot another complex enhancemenet onto the to-do
list of some future codefest

what say?

rudy