Java - should I represent user ids with int, long or Integer?

Question

When I need to do numerical comparisons of user ids, should I do something like:

int numeric_user_id = Integer.valueOf("1234343");

or is it better to put that into a long, or keep it an Integer?

Thanks!

Answer 1

Unique Identifiers should not carry any special semantic meaning; ever . UUID or GUID types were designed just for entity identifiers, so that you don't infer any semantic meaning to them, that is what makes them opaque.

One of many practical benefits is that they will never clash when importing and exporting data to different databases, ie; development, qa, production , or when used in a cluster. If you use plain old numbers, especially auto-incrementing numbers, each database will have a different user for the same number and it is next to impossible to keep out dupes and other bad data from creeping into the different systems. UUID/GUID solutions completely avoid this kind of problem.

There are lots of reasons not to use the id for anything other than ids. What happens when you have more than 30000 beta users, what happens when you want to kick some people out of the beta user program, what happens when ... ?

As for using ids for business logic like identifying beta users, don't use the id for that, use another attribute flag to identify them. You could have a boolean flag, or an enum or some other flag, or even combine the fact that they are a beta user with when they joined the beta program by having a nullable timestamp , that would flag them as such, but that could end up being less flexible by leaking concerns; but it may be appropriate in some cases.

public interface Identifiable {

    public UUID getUUID();
}

public interface BetaUser extends Identifiable {

    public boolean isBetaUser();
    public Date    joinedBetaProgramOn();
}

int , long , and other number types should only be used for math ; not for identity management or business logic un-related to mathematical concerns.

if you want to get the nth user of the system, then sort them by join date and take their index from the list

Answer 2

I'd suggest using a Long (an object, not a primitive), precisely because it allows a null value. There will likely be cases where you will want this when operating on transient User objects (copying, cloning, etc.).

If you're going to persist them in a database, however, make the userId column not-null (better yet, make it the primary key).

Use Long rather than Integer so that you don't have to worry about overflow in the future.

Don't compare userIds or try to use them for any logic purpose (such as figuring out who is a beta user) - keep them as opaque identifiers. If you need to know who is a beta user, introduce data (like, say, accountType) to track that.

As others have mentioned, a UUID is another perfectly acceptable way to go, and has the bonus of being fairly opaque in it's nature (though not completely), pretty-much enforcing the "don't interpret userIDs" rule.

Answer 3

I would say put it into a long primitive. The reason is that, assuming you never want it to be null, you will never have the accidental situation where a "getUserId()" method returns a null user id and the error is not caught.

If you store it into a long vs. Long or Integer, the system will detect it as a runtime error immediately.

if you store it in an actual object, Like Long, it may be null. If this is an error, your code may fail at a later point in an unpredictable, possibly damaging way. It's best to detect errors as early as possible.

If it can be null and you use a real object, be sure to write code to handle the null case.

As for int vs long, you will have to make the decision based on whether you think it will ever exceed the size of an int.

This is also assuming your only choice is the normal numeric types. Perhaps there is another data structure that is more appropriate for such IDs,

Answer 4

在这种情况下，最好的方法是使用单独的基本类型而不是整数。

Answer 5

Strange that still no answer advocated int . As automatic incremented primary key that will suffice in 99.99% of all applications. Furthermore user references are many (creator, last-editor, ...) so a bit saving as opposed to a long is nice.

Long will come into use as primary key if you have things like user notes and other historic items.

Rule: before long start with int , as a modification to java sources and database is easy.

Answer 6

The max value for an int is 2,147,483, 647 which is over 2 billions. In most situations, int should be more than enough.