Is To Manually Assign An Entity's IDs A Good Idea?

Question

We're developing a system to replace an old application from our clients.

Actually there are many entities (like merchants, salesmen, products, etc) that must have a manual assigned ID -so they can be integrated with other existing systems. i.e. accounting.

We think the best solution is simply allow the user to assign the entities IDs manually when the entity is being created; we're going to suggest him the next available ID, and the user will be able to change it if they want. no updates allowed! (muahahaha)

We'll be glad to hear your thoughts about. Pros / Cons

Thanks in advance :)

PD: Do you know any documentation about? -Entities and IDs-

---

UPDATES

• We think there should be cases when this applies and do not. so...
• Additionally there are cases when the client literally wants that a given entity has an Id they bring. organization internal codes I think.

Answer 1

Never, ever, ever let the user have access to assign or create the underlying objects identifier. These must be system maintained.

Imagine the nightmare of trying to figure out which entity a related entity actually goes with in the event that the user picks an id that is already in use.

Instead, you should have a regular entity ID of some type (int, guid, whatever) that the system assigns and uses for links to all dependent objects. Then have an "external" id of some sort that the user can put their own identifier in.

Maybe that relates to an external system in some way, maybe not. Point is, you'll be able to maintain your own consistency regardless of what they do.

Answer 2

What is usually done is to specify your own, usually hidden, identifier that is used internally. Then create a second identifier that the user can use as a separate data field. Also, you can get into a bit of a concurrency trouble if you try to suggest the next ID.

Answer 3

I guess this boils down to a separation of concern issues. If you've been developing apps for more than a year you should already know why you need an object identifier in your rdb's, if your users need to concern themselves with assigning and/or managing your underlying object identifiers then you have a design problem, and this problem is that you are mixing data access/storage concerns with business logic. As others already said the best approach is to have two identifiers, one that is transparent to the user and used internally in your app and the other to be used in your integration processes.

I've seen a similar case while working with retailers, there's an id and a product's SKU, the sku itself could be the id yet to allow for a good design we have both.