views:

1007

answers:

4

We use a base entity with properties such as version (datetime needed for NHibernate) and guid (as key).

It also has an Id (int) field with two functions. Firstly to relate to legacy application key if there is one. Secondly as a shorthand code: for instance files are sometimes created based on these which would look ugly and long using our guid key. My question is not really about pros and cons of base entities but about up-typing this Id to Int64?

It would not affect how it is stored within our MS SQL Server database. Would it have more cost in our cache and memory?. Is this really that much of a worry?

I am interested to hear other downsides besides performance. Consider also these values will probably be exposed through web services to third parties in time too.

The alternative is to deal with the exceptions of larger integers as they arise and implement them specifically in derived entities. The downside is this would need to be done in code and what would we do when we discover some cases when in production of larger integers? There would of course be input validation to stop actual errors but it may restrict expanding data.

+1  A: 

Portability... though C# isn't really know as lingua franca if you're going for portable, so this might be moot for your perspective?

andy
Where would the portability issue be? I'm not saying there isn't one, just confused about where it might be. I can't easily think of a common platform which doesn't have a 64-bit integer type.
Jon Skeet
I'd say that should not be the problem if all platforms implement their types based on the Common Language Specification. Or am I wrong?
lowglider
There's more to portability than the CLR. Rumour has it there are other platforms out there ;)
Jon Skeet
+4  A: 

If your app is running on a 64 bit CPU then probably not much difference at all.

On a 32 bit CPU, a 64 bit integer will be more processor intensive to perfom calculations with.

There is also the obvious memory use.

Ady
+2  A: 

Only you can answer how much of a concern the space in your cache is. If that's the cache key and you've got some huge blob as the value, then adding an extra 4 bytes to the key isn't going to make much difference. If all you're storing is the ID, then obviously it's going to have a more proportionally significant effect.

How much memory is spent storing your IDs at the moment?

Jon Skeet
it's somewhere in between, we try to keep cached objects slim, certainly no blobs. i'll +1 on your cost point and comment below on integration. anything else you can think of for charity?
dove
+3  A: 

Well, int64 uses 8 byte of memory storage, while int uses 4 byte... however, you pointed out most of the disadvantages already. Of course calculations performed will also be slower on many systems (a 64 bit system running in 64 bit mode can perform operations on 64 bit as fast as on 32 bit, but a 32 bit system needs to perform extra work, that means adding two 64 bit numbers is performed by two 32 bit adds plus some extra code - other math operations will be equally broken down into 32 bit operations). However unless you store millions of these numbers and perform tons of operations with them, I doubt you will see any performance difference, though, neither in CPU time nor in memory.

Mecki