alt Hacker News> I think you are missing the actual problem I am talking about: where does the user take the transaction ID from? Do you expect the users to remember all transaction IDs your system ever generated for them? How would they know which transaction ID to ask about? Are they expected to keep some metadata that would allow them to identify transaction IDs? But if there is metadata that enables identification of transaction IDs then why not use it instead of transaction ID in the first place?
Your notion that you can avoid sharing internal ids is technically true, but that didn’t mean it’s a good idea. You’re trying force a philosophical viewpoint and disregarding practical concerns, many of which people have already pointed out.
But to answer your question, yes, your customer will probably have some notion of a transaction id. This is why everyone gives you invoice numbers or order numbers. These are indexes back into some system. Because the alternative is that your customer calls you up and says “so I bought this thing last week, maybe on Tuesday?” And it’s most likely possible to eventually find the transaction this way, but it’s a pain and usually requires human investigation to find the right transaction. It’s wasteful for you and the customer to do business this way if you don’t have to.
> Your notion that you can avoid sharing internal ids is technically true, but that didn’t mean it’s a good idea. You’re trying force a philosophical viewpoint and disregarding practical concerns, many of which people have already pointed out.
What some call "philosophical viewpoint" I call "essential complexity" :)
> But to answer your question, yes, your customer will probably have some notion of a transaction id. This is why everyone gives you invoice numbers or order numbers.
We are in agreement here: externally visible identifiers are needed for many reasons (mostly technical). The discussion is not about that though but about what information should be included in these identifiers.
> This is why everyone gives you invoice numbers or order numbers.
And there are good reasons why invoice or order numbers are not randomly generated strings but contain information about the invoices and orders they identify.
My claim is that externally visible identifiers should possess a few characteristics:
* should be based on the data they identify (not detached from it)
* should be easy to remember (and that means they should be as short as possible, they should be easy to construct by a human from the data itself - so they cannot be hashes of data)
* should be versioned (ie. they should contain information somehow identifying the actual algorithm used to construct them)
* should be easy to index by database engines (that is highly db implementation dependent unfortunately)
* can be meaningfully sortable (that is not strictly a requirement but nice to have)
Coming up with an identifier having these characteristics is not trivial but is going to pay off in the long run (ie. is essential complexity).