From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | ourdiaspora <ourdiaspora(at)protonmail(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: database design with temporary tables |
Date: | 2021-08-29 16:50:15 |
Message-ID: | 918c3f8f-cd38-aace-5e6d-7a67a764648e@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 8/29/21 9:36 AM, ourdiaspora wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Sunday, August 29th, 2021 at 5:24 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>
>>
>> Presumably not. Temporary tables only live at most for the length of a
>>
>> session. It would be a really bad idea to hold sessions open for 24
>>
>> hours.
>
> Is there an alternative scenario, such as the user is able to create a new table with saves the session data for a maximum time (such as 24 hours), even up to a certain time if the web browser crashes for example?
This is a it depends answer. Some factors in play:
1) Number of users over say a 24 hour period.
2) The size of the CSV files.
3) Is the data merge a one time thing or can it be repeated in a time
period.
4) Are users going to be repeat customers?
For this sort of thing I write out a detailed outline of the
who/what/why/where/when. In doing that answers tend to follow.
>
>>
>> The abo
>>
>
> Incomplete response?
>
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2021-08-29 16:53:43 | Re: database design with temporary tables |
Previous Message | ourdiaspora | 2021-08-29 16:49:29 | Re: database design with temporary tables |