On Mon, 14 Apr 2014 15:22:13 -0700 Robert DiFalco <robert.difalco@xxxxxxxxx> wrote: Hi Robert, > But then I lose a bunch of data like the TIMESTAMPTZ of the call, answer, > connection, etc. Btw, currently these tables never need to be UPDATEd. They > are immutable in the current design. Yes, but you wrote : >Occasionally I will want to know things like "When was the last time a user >answered a call" or "How many times has a user been called". With your schema, you would have to query several tables each time. Queries will get messy in a hurry, updates and DDL changes too. > And in the end I'm not sure how the > proposal of one table and a state that is updatable changes the basic > thrust of the question. For example, getting last call, last answered, > total called, total answered. If the state of a call transitions from > called to answered then making it a field loses all the data with the > previous state, make sense? > If you need this, you can use a schema that accommodates it. (off the top of my head, insert a new record instead of altering an existing one, and create a hierarchy with parent records that point to an original call, may be with a 'parent' field and recursive queries. You probably have many requirements that I'm not aware of, but this one can be met) -- Salutations, Vincent Veyron http://marica.fr Gestion des contentieux juridiques, des contrats et des sinistres d'assurance -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
