So the memory engine stores a table by creating a unique list of values for a field and an index with pointers to those values. So the more unique values you have the more memory footprint your taking up, the more tables with more unique values in your model the more memory you're taking up.
I would consider a couple of things. One are all the fields actually necessary? If not, drop those that aren't from your applications. Is the unique key actually necessary, because it's unique it will inflate the size of the index and pointers so if you don't actually need it then combine the tables and drop that unique key after you combine them. While it may be a pretty wide table you may see a reduction in memory footprint because of the deduping. Basically anywhere you can alleviate unique values do so and you'll generally see your overall memory footprint reduce. If you have timestamps and don't need timestamps definitely drop those. If your date fields have timestamps in them, change it to only the date. If you still need timestamps break them out into an hour, minute, second field so that they have very low cardinality. Addresses, chop them up into their elements so that they have lower cardinality. Do the same with phone numbers.
The caveat here is that you might need seperate tables for certain measure calculations to work properly without tons of set analysis. You have to weight the tradeoff in set analysis performance vs. memory consumption.
.png "Luminary Alumni"){kind=icon}
