- one table for the years names/ids/etc. (1970, 1; 1971, 2;
1973, 3;
)
If you _do_ need this table (because you want to constrain your
statistical data to only contain a specific set of years, or
because you
need a quick list of available years to select from): Make the year
BTW, You didn't actually use type text for your year column, did
you? No
quotes needed then. Otherwise you'd have to make sure your year values
are all the same length or sorting gets... interesting.
Yep, my comment just before concerns especially this paragraph, I
guess. With not only
I find it far easier to maintain normalized tables that produced
non-normalized ones (for things like data warehousing) than it is to
maintain non-normalized tables and trying to produce normalized data
from that.
Ok, I do understand that.
So, instead of the earlier mentioned database design,
Stefan Schwarzer wrote:
BTW, You didn't actually use type text for your year column, did you? No
quotes needed then. Otherwise you'd have to make sure your year values
are all the same length or sorting gets... interesting.
Yep, my comment just before concerns especially this paragraph,
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
Stefan Schwarzer wrote:
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'
What would you recommend for say, 500 global national statistical
variables,
500 regional and 500 subregional and 500 global aggregations?
Years being
covered having something between 10 and 60 years for each of these
variables. All available for 240 countries/territories.
I generally
A few more comments on your table design.
Stefan Schwarzer skrev:
So, instead of the earlier mentioned database design, I would have
something like this:
- one table for the country names/ids/etc. (Afghanistan, 1; Albania,
2)
There is a well-established natural key for countries -
Ah, but there is a standardised list of country-codes ideal for the
DBA since the code is (usually) easily understandable.
http://en.wikipedia.org/wiki/ISO_3166
The only problem might be if historical data uses old boundaries
(e.g. Soviet Union, Yugoslavia).
Yep, have all of them (ISO-2,
Stefan Schwarzer wrote:
Ok, I do understand that.
So, instead of the earlier mentioned database design, I would have
something like this:
- one table for the country names/ids/etc. (Afghanistan, 1; Albania,
2)
- one table for the variable names/ids/etc. (GDP, 1; Population, 2;
Stefan Schwarzer skrev:
What would you recommend for say, 500 global national statistical
variables,
500 regional and 500 subregional and 500 global aggregations? Years
being
covered having something between 10 and 60 years for each of these
variables. All available for 240
Alban Hertroys wrote:
If you _do_ need this table (because you want to constrain your
statistical data to only contain a specific set of years, or because you
need a quick list of available years to select from): Make the year
primary key and drop the artificial index.
Years are perfectly fine
12 matches
Mail list logo
