Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 15B809FB1ED for ; Mon, 6 Nov 2006 18:51:57 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 99565-02 for ; Mon, 6 Nov 2006 22:51:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by postgresql.org (Postfix) with ESMTP id 296D49FA497 for ; Mon, 6 Nov 2006 18:51:51 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id k3so871353ugf for ; Mon, 06 Nov 2006 14:51:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Mv3wGnU8NoHdiyLglmYtxZIAVOKlF3FOXKyPr1ieDN8nKD7sKJKRTKF1hmk7M++jP8Lt1TusgD3C9Z9Hho5WB3gD54Szd/DT4OeOlKKv+J8T0o1upmkRk5L8LLrzdF9dzOctbLJh1AvFM0EO7IDBCocNOPkhkc+pF0Kp24yk4oA= Received: by 10.78.21.7 with SMTP id 7mr4054822huu.1162853510881; Mon, 06 Nov 2006 14:51:50 -0800 (PST) Received: by 10.78.136.6 with HTTP; Mon, 6 Nov 2006 14:51:50 -0800 (PST) Message-ID: Date: Mon, 6 Nov 2006 16:51:50 -0600 From: "Aaron Bono" To: pgsql-sql@postgresql.org Subject: Fwd: refining view using temp tables In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_44788_8246884.1162853510649" References: <7097897.post@talk.nabble.com> X-Google-Sender-Auth: a85a8833adddde70 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/90 X-Sequence-Number: 26742 ------=_Part_44788_8246884.1162853510649 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: Aaron Bono Date: Nov 6, 2006 4:51 PM Subject: Re: [SQL] refining view using temp tables To: BeemerBiker Cc: pgsql-sql@postgresql.org On 10/31/06, BeemerBiker wrote: > > > Using postgre with dotnet VS8. I came up with a scheme of having a web > user > search thru the database and selecting into a temp table. Then a further > "refined" search would use the temp table as input and another temp table > as > output. Then swap the source and destination so as to not use up > resources. > Maybe this is not a good mechanism. I found right away I could not easily > check for table existence nor drop non-existent tables without getting a > server error (even with try {} catch {}). > > I may have the same user bring up two or more pages during the same > session. > Ditto for other users. I would not want to code up temporary names using > timestamps and usersnames if I could avoid it. It would be nice if the > sql > engine would handle this for me. Can someone suggest how postgresql > could > handle a google like "search within results". The best approach will probably vary depending on the volume of usage on your site. One thing I would try is to create a table for searches and search results with a primary key equal to the user's session ID or log in ID. This would only give them one search but if you need more you can use a serogate key. Then have everyone use the same table - no temp tables needed. Table: user_search user_search_id (PK), session_id (indexed), create_dt, last_access_dt user_search_param (one record for each search parameter they entered for the filter) user_search_param_id (PK), user_search_id (FK), param_name, param_value user_search_results (one record per record returned in search) user_search_results_id (PK - this may not be necessary), user_search_id (FK), sort_index (to help preserve sort order), values (this can be CSV, XML or even broken into another table) Then you can add a process that regularly deletes searches who's last access date is older than so many minutes (cascade delete that is). Or you can add a trigger that fires off this clean up whenever a new search is added. ================================================================== Aaron Bono Aranya Software Technologies, Inc. http://www.aranya.com http://codeelixir.com ================================================================== -- ================================================================== Aaron Bono Aranya Software Technologies, Inc. http://www.aranya.com http://codeelixir.com ================================================================== ------=_Part_44788_8246884.1162853510649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: Aaron Bono <aaron.bono@aranya.com>
Date: Nov 6, 2006 4:51 PM
Subject: Re: [SQL] refining view using temp tables
To: BeemerBiker <jstateson@swri.edu>
Cc: pgsql-sql@postgresql.org

On 10/31/06, BeemerBiker <jstateson@swri.edu> wrote:

Using postgre with dotnet VS8.  I came up with a scheme of having a web user
search thru the database and selecting into a temp table.  Then a further
"refined" search would use the temp table as input and another temp table as
output.  Then swap the source and destination so as to not use up resources.
Maybe this is not a good mechanism.  I found right away I could not easily
check for table existence nor drop non-existent tables without getting a
server error (even with try {} catch {}).

I may have the same user bring up two or more pages during the same session.
Ditto for other users.  I would not want to code up temporary names using
timestamps and usersnames if I could avoid it.  It would be nice if the sql
engine would handle this for me.   Can someone suggest how postgresql could
handle a google like "search within results".

 
The best approach will probably vary depending on the volume of usage on your site.

One thing I would try is to create a table for searches and search results with a primary key equal to the user's session ID or log in ID.  This would only give them one search but if you need more you can use a serogate key.  Then have everyone use the same table - no temp tables needed.

Table:
user_search
    user_search_id (PK),
    session_id (indexed),
    create_dt,
    last_access_dt

user_search_param (one record for each search parameter they entered for the filter)
    user_search_param_id (PK),
    user_search_id (FK),
    param_name,
    param_value

user_search_results (one record per record returned in search)
    user_search_results_id (PK - this may not be necessary),
    user_search_id (FK),
    sort_index (to help preserve sort order),
    values (this can be CSV, XML or even broken into another table)

Then you can add a process that regularly deletes searches who's last access date is older than so many minutes (cascade delete that is).  Or you can add a trigger that fires off this clean up whenever a new search is added.

==================================================================
   Aaron Bono
   Aranya Software Technologies, Inc.
   http://www.aranya.com
   http://codeelixir.com
==================================================================

--
==================================================================
   Aaron Bono
   Aranya Software Technologies, Inc.
   http://www.aranya.com
   http://codeelixir.com
================================================================== ------=_Part_44788_8246884.1162853510649--