I'll do this backwards
If a database has two data types - TEXT (character arrays) and INTEGER (4 or 8 byte integral values), will 'p' ever be 'small' enough to transform an INTEGER value in-situ or in place?
No. Homomorphic ciphertexts are still way to big to be stored in a 32 or 64 bit integer. You would likely store the ciphertexts in a string (encoded in some way).
When the authors discuss a small modulus p used for the transition from (n, log q) to (k, log p), how 'small' are they talking about?
They give the following hint in the paper
To give a hint as to the magnitude of improvement, we typically set $k$ to be of size the security parameter and $p = poly(k)$. We can then set $n = k^c$ for essentially
any constant $c$, and $q = 2^{n^\epsilon}$. We will thus be able to homomorphically evaluate functions of degree roughly $D = n^\epsilon = k^{c\cdot\epsilon}$ and we can choose $c$ to be large enough so that this is sufficient to evaluate the ($k$; $\log p$) decryption circuit.
So the size of $p$ is polynomial in the size of the security parameter. Note that the size of $q$ is $n^\epsilon$. $n$ is exponential in the size of the security parameter. So you go from exponential in the security parameter to polynomial, but we are still talking very, very large compared to a 32 or 64 bit integer. I believe ciphertexts in other FHE systems are on the order of kilobytes or megabytes and those were systems that improved upon this scheme.
