Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function - Mailing list pgsql-general

From APseudoUtopia
Subject Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
Date
Msg-id 27ade5280906280922p2bd7ca35x549ae5993223a87a@mail.gmail.com
Whole thread Raw
In response to Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function  (justin <justin@emproshunts.com>)
Responses Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
List pgsql-general
On Sat, Jun 27, 2009 at 9:13 PM, justin<justin@emproshunts.com> wrote:
> APseudoUtopia wrote:
>
> Hey list,
>
> I have a query which allows users to "Catch up" on read posts on the
> forum. It works by either updating or inserting the "last post read"
> number from every forum thread into the readposts table (for that
> userid and threadid combination, of course). Here's the table
> structure:
>
>
> Wouldn't a view be better than having a table that is deleted and updated
> all the time.  I would add a field in the user table called  last_login type
> timestamp  then do a select from the forums table to generate this table
> where last_login <= FormTimeStamp .
>
> I don't see the point having this table when a view would work better.
>
>
--snip--
>
> Creating a view would work better and than creating a table to track this.
> I would think this website tracks the last time the user logged in
> correct???  This is going to create allot of over head maintaining this
> table when a simple select statement will work so much better if i
> understand what you are doing.....
>
>
>

That wouldn't work. What if a user logs in, reads only one forum
thread, then logs out (intending to read all the other forum threads
at some point in the future when they log in again). If I used a VIEW,
it would automatically consider all those unread forum posts to be
read when the user logs out.

pgsql-general by date:

Previous
From: David Fetter
Date:
Subject: Re: Replication and coding good practices
Next
From: Whit Armstrong
Date:
Subject: partitioning question -- how to guarantee uniqueness across partitions