Re: Normalized Tables & SELECT [was: Find "smallest common year"]

Поиск
Список
Период
Сортировка
От Stefan Schwarzer
Тема Re: Normalized Tables & SELECT [was: Find "smallest common year"]
Дата
Msg-id 75A1C775-C8AD-4546-BE40-CC5D8DD42ACB@grid.unep.ch
обсуждение исходный текст
Ответ на Re: Normalized Tables & SELECT [was: Find "smallest common year"]  (Alban Hertroys <a.hertroys@magproductions.nl>)
Ответы Re: Normalized Tables & SELECT [was: Find "smallest common year"]  (Alban Hertroys <a.hertroys@magproductions.nl>)
Список pgsql-general
> An entirely different question is whether it is a good idea to write a
> range as a value that the database cannot interpret correctly
> (referring
> to the '1970-75' notation). You cannot group records by value this way
> if you need to (for example) combine data from '1970' with data from
> '1970-75'.
>
> But you seem to use these values just for labels, which I assume are
> unique across years (eg. if you have a value '1970-75' you don't have
> values '1970', 1971'..'1974'), in which case this is safe to use. As
> pointed out by several people earlier, they make an excellent foreign
> key too (provided they're unique).

Yep, this is question I posed myself too. In the moment, when doing
for example "per Capita" calculations on the fly of a variable which
has something like 1970-75, I would then sum up the Total Population
over the given period, divide it through the number of years and then
use it with the selected variable to get the "per Capita" data.

But if I would instead insert yearly data, it would mean that it had
five lines with the same values. No problem with that?

Stef

В списке pgsql-general по дате отправления:

Предыдущее
От: Mike Charnoky
Дата:
Сообщение: Re: more problems with count(*) on large table
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: more problems with count(*) on large table