I am working on a winform (.NET) application which includes Orders, Invoices, Service Orders, Ticketing etc.
It it necessary for these enities to be sequential when numbering their IDs? IMO no. Take an order for instance, it can only be valid once it passes thorugh the business layer, during that proocess another order could've been created, approved and saved with the number 2 while the order which was created earlier with id 1 failed validation.
This seems to open a can of worms as to which layer assigns the order number, no?
Currently I am using non-sequential numbers prefixed with an identifier for the entity. Example, order uses OR-123. Is this a good idea?
Thanks
If the field in question is your primary key, sequential numbers are faster to insert, even if you skip from 1 to 3, etc.
But sequential numbers do introduce a security issue: people "guessing" URLs, transposing numbers accidentally, or giving away business data (how many users you have, etc.).
One option is to use a GUID (uniqueidentifier type). It's not human-friendly for speaking out loud or typing in, but it is sufficiently random and unique.
If you are using SQL Server 2005, the new SequentialID() function will return a sequential GUID, which gives you both the uniqueness you need, and fast insertion into your table.
If you choose to use some sort of random-ish number, I encourage you to also have a smalldatetime column defaulted to GETDATE() in your table so you can order and filter your rows by the date of creation.
You should ask your business contact whether numbers really really really need to be sequential, not us.
And tell that same business person that it is, in most circumstances, as good as impossible for a computer system to give watertight guarantees about this.
You only need to have sequential ids if it is a valid business requirement.
Accounting and general ledger folks like sequential numbers and if the numbers are missing they want to know why. It is an accounting practice that if it is not done to specs can cost a business time and money.
Sequential numbers are not necessary, and in some scenarios are a bad idea (in security-conscious systems where guessing is a problem). But it is relatively common to let the RDBMS handle this - most support an
IDENTITY
auto-incrementing type (although it gets more complex with multiple distributed master servers). Another option isGuid
of course - little chance of duplicates.The prefix approach is quite handy for quickly identifying numbers - but you can choose to just prepend the "OR-" at the layers above the db.
Accounting rules in the country the application will be used might require sequential numbers on invoices.
You users might be used to think in terms of sequential numbers. Maybe the employees place bets on who gets to pack order number 10000? They would probably be quite upset if someone told them that the bets are off, because of the new computer system.