Possibility of moving to Int64 for Content Ids

I know this sounds a bit adventurous, but I'm thinking the standard Int32 used for Ids might be a bit restricting in some cases.

I've just run into this very scenario, when writing an orders record. I solved it by removing it as a content part, and making just an ordinary table, with a long type for an Id. But it would have been nice to have it as a contentpart.

Problem being that if I somehow max out the customers at Int32's max value, that would only allow one order per customer, which wasn't gonna work obviously.

I remember playing round with Sun's Project Darkstar a few years ago, and in their wisdom, they used longs for Ids. Now I'm thinking they understand Enterprise software, so they'd probably be right in stipulating that type for an Id.

I know it would make a lot of work in transition, and it may not be fiesible, but it was just a thought..

Well, to be honest, I can work round it, so not a major problem, but I do think that actually implementing a long isn't gonna have a drastic performance impact. Project Darkstar that I mention was a low latency mmo game server, and they had no probs with
the long Ids (but bigger problems with network latency). That's not a good example though, cause it didn't scale well last i heard lol..

To provide some context, we've had this request many times, from people who thought that they may reach the limit. However, no one to my knowledge ever has. Furthermore, if you reach that many content items, it's almost certain that you would hit lots of
fun new performance problems and that short ids would be the least of your concerns.

Personally I would prefer GUIDs. My reason for this is moving toward a more enterprise level of administration with multitenancy, e.g., global navigation, global search, global tags, possibly global content picking or referencing for inter-site
linking without link rot, and maybe global users if roles included the ability to reference tenants. If GUIDs were used then they could be carried into the global tables without needing to first map records. This is assuming all site tables are being
contained in the same database.

I know there was a discussion on using GUIDs for identity but I don't remember what the specific reasoning was on not being able to use them with NHibernate.

I strongly veto GUIDs. We have better ways of handling identity, and table IDs columns are internal and don't have to be consistent across instances/datacenters/younameit. Identity is a separate concern (see import/export). If you really want to use GUIDs,
by the way, you can: just add the Identity part. It's using GUID as identity for those items that don't have a better one.