[thesite] CodeFest: Flights and LOTTD

[.jeff]

Joshua,

 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
 > At 01:58 PM 9/21/2001, you wrote:
 >
 > I just looked over the db architecture a little and it
 > seems that there is already an association table
 > created for managing the many-to-many relationship:
 >
 > http://members.evolt.org/rudy/oracle4.gif
 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

yes, there indeed appears to be an association table in place.  at this 
point in time it's definitely not in use though.  there's far more to 
consider in this situation though.  take a look at the categorys table and 
notice the connection to the cattype table.  i stand by my original 
statement that it's much more involved than simply using an association table.

 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
 > The relationship does not contain any additional
 > information, however, which may be what is required
 > to gain full value for the investment.  Things that
 > you can do with the relationship table is include the
 > views (how many times the article was viewed when it
 > was within a specific category),
 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

all good ideas.

 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
 > but introduces the complexity of deciding which category
 > to jump a user to when they click on the article off the
 > homepage!  The logical solution would be to include a
 > default category id, which could be handled by the
 > current category_id in the content table.
 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i think i'd lean towards calling it the preferred category, as opposed to 
the default.  it's just semantics though.

 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
 > You are right that there are a lot of things to discuss
 > and it is best not to jump in without thinking about
 > them.  However, I do not believe that tabling the idea
 > is the best answer.  Instead, we should bounce the ideas
 > around, examining impact to users and costs involved in
 > implementation, and then decide to move on it or hold
 > during the first week of October.  That gives us almost
 > 2 weeks to think about this.
 ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

there are far too many other things that already deserve development time 
at codefest to have time left to dedicate to this.  instead, there should 
be finalizing discussion taking place on the existing issues in order to 
reach concensus on solutions before development.

thanks,

.jeff