> Question 2: Am I correct to assume that a value defined as integer will be more efficient in artihmetic functions (eg, sum(..)) than having the integer value stored in a Numeric field? Although I would expect it to be very marginal... An integral value that fits in a 64-bit two's-complement integer field is stored as an VARINT (1 to 8 byte integer) when stored. A floating point value (that has a non-zero fractional part) is stored as a 8-byte IEEE-754 float. An INTEGER affinity means that the value will be stored as an INTEGER, if it can. A REAL affinity means that the value will be stored as a IEEE-754 float, if it can. A NUMERIC affinity means that stuff that looks like a number will be stored as an INTEGER if possible, but if the number has a fractional part or is larger than will fit in an INTEGER then as REAL. > Question 2: Am I correct to assume that a value defined as integer will be more efficient in artihmetic functions (eg, sum(..)) than having the integer value stored in a Numeric field? Although I would expect it to be very marginal... No. An INTEGER is an INTEGER, a FLOAT is a FLOAT, a NUMERIC is whichever is appropriate in the circumstance. > I find however that I frequently seem to need to cast these columns as integer in order for maths to work correctly. This I do not understand. There is no difference between a NUMERIC value which is an integer and an INTEGER value which is an INTEGER -- they are both INTEGER and behave exactly the same.