From: | Frank <frank(at)chagford(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: When to store data that could be derived |
Date: | 2019-03-24 09:29:14 |
Message-ID: | 16168610-0b87-252d-bd6c-cf1e6429bccb@chagford.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2019-03-24 11:11 AM, Tony Shelver wrote:
> Not the answer you are looking for, but...
>
> I'd suggest trying to create a non-trivial set of dummy data to test your
> assumptions before deciding on a route.
> It's saved my (professional) life a few times over the years when dealing
> with untested designs and new (to us) technology.
>
> Some years ago we were implementing an identity management system for a
> large US bank, with SQL Server as the store, with a planned integration to
> the id / access / permissions of some 300+ systems, targeting 30k plus
> users.
>
> Requirements kept changing as we added new systems to the initial mix,
> which the Id management package couldn't handle out the box, so we had to
> implement a custom design. We had to choose between 2 database designs,
> one being fully 'normalized' (considering that everything was an object')
> and one where we made some assumptions and fixed some table structures in
> the interest of performance.
>
> Eventually we spent a few days adding non-trivial amounts of test data to
> the proposed designs and it became quickly became very apparent that option
> 1 was unworkable once we got beyond 10 systems or so.
>
Good advice - much appreciated.
Frank
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2019-03-24 09:55:10 | Re: When to store data that could be derived |
Previous Message | Tony Shelver | 2019-03-24 09:11:29 | Re: When to store data that could be derived |