Leo Peysakhovich:
"In light-load transactional systems (1-2 transactions per second) you can produce a unique id based on the timing characteristics of the transaction itself. I use this method for years and have no problems.
"And this method used by company for 4 years and has no issues in our environment."
Jeff Moden:
"I agree with Rob and Alex... I'd also like to add that using something that you know "could" fail but hasn't so far (UDF_ID function) is a bit like sitting under the sword of Damocles."
I have to agree with Jeff on this one. What is light load today is 50-users banging away 20 transactions/second tomorrow, and lord knows what next month. I've been a programmer for over 25-years. I've worked on PC platforms with VB and other languages for over 10 of that. I have a class I wrote very early on in my client-server days. It has been revised once, when we went from RDO to ADO. It has been redesigned once for ADO.NET. Other than that, it is in place in almost a dozen locations I have worked at (I'm a contracted resource). It does ALL data handling. It opens connections, returns datasets, sets parameters, executes stored procedures, disconnects datasets, adds, updates, deletes rows from tables...
Good designers not only take into account what is happening today, but what might happen next week or next month or next year. I don't want to be out there redesigning my code every 4-months because the user made a process change that was within my ability to have anticipated. Look at the fiasco the Y2K problem caused.
I wouldn't code a program to determine if a year was a leap year just by determining if the year was evenly divisible by 4. Because 2100 is not a leep year. You might think, "So what, I'm sure not going to be alive in 2100, and besides, my program probably won't even be running in 2100."
As a teacher you do not want to be presenting bad examples. I don't want to provide someone code, a methodology, a concept, and say, "this will work as long as... and it is not an even numbered day of an odd month." It should work for all scenarios. You could use a BIT field as a primary key as long as you never have more than two records in the table 🙂