Influence of table width and longitude on memory_footprint?

[datanibbler]

Hi,

I have the following scenario:

- There is a list (Excel) with details about costs related to our fleet of vehicles

- I assemble this list from four files actually:

     - There are two plants - those vehicles are different all right, so I concatenate them

     - There are two years - after concatenating the plants, I join those because the vehicle_IDs are the same from year to year.

So I have, in the resulting list, one field (ex.) for the monthly_rent_2014 and one for the monthly_rent_2015 which might be different - there are others, too.

I'd like to change this and make the year and month into a dimension. That would mean there would (ex.) be just one field "monthly_rent" - the table would get less wide, but significantly longer.

=> What influence will this have on the memory_consumption of my app? I guess there is a tradeoff, but in general, is it preferable to have a wide_and_shorter table or a less_wide_but_longer one?

Thanks a lot!

Best regards,

DataNibbler

[Gysbert_Wassenaar · Accepted solution]

You'll have to test it, but the memory consumption could well go down. By putting the rent figures for all periods in one field it's possible that the remaining symbol table for the rents field is smaller than the two (or more) symbol tables for the separate fields. It depends on the cardinality of the values in the rents fields. See this blog post: Symbol Tables and Bit-Stuffed Pointers

[datanibbler]

Thanks Gysbert!

I'll try it and see for myself. I would actually prefer that, it just looks neater and I don't like having several fields for basically the same thing.

Best regards,

DataNibbler