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' 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? Not entirely what I suggested, but also a viable solution, sure. I was suggesting to add a column to your yearly data marking the end of the range. Given your above examples, you could then do queries like: SELECT population / num_years FROM my_data; (Assuming you add the length of the interval as a number of years, which seems plausible because you don't seem to calculate with any intervals not dividable by a year). Adding this additional column may justify putting the years (and their durations) into their own table. -- Alban Hertroys alban@xxxxxxxxxxxxxxxxx magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World // ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
