Re: UUID column as pimrary key?
От | Scott Ribe |
---|---|
Тема | Re: UUID column as pimrary key? |
Дата | |
Msg-id | 96857559-BBD2-4ECA-9F8F-2892FCF27AD3@elevated-dev.com обсуждение исходный текст |
Ответ на | Re: UUID column as pimrary key? (Bill Moran <wmoran@potentialtech.com>) |
Список | pgsql-general |
On Jan 6, 2011, at 8:14 AM, Bill Moran wrote: > I don't give a fuck how small the chance of conflict is, the only > viable option for that chance is 0. Period. Any argument to the > contrary is stupid, asinine and outright negligent. Do you give a fuck about the chance that bits will flip in the RAM and not be detected? Do you give a fuck about the chancethat bits will flip in whatever persistent storage is in your device and not be detected? Do you give a fuck aboutthe chance that bits will be flipped in the network and not be detected? Do you give a fuck about the chance that atransistor will go into a metastable state instead of flipping, and lock up the device and lose data not yet saved? Well,of course you do. But now what are the relative odds? All of these things can happen already (and all of them can happenthe very first time you use it), so already your system is not precisely 100% reliable. Now is the risk of UUID collisionsomewhere near the same as these risks, or orders of magnitude higher, or orders of magnitude lower? It does matter. > However, you > should always take 5 or 10 minutes to consider whether your application > is one of the .00000000001% that can't tolerate the tiny risk. If an application/device truly can't tolerate a risk of an error of 1 in 10^-16, that's a problem because you can't builda device without risk of error below some threshold (in that general neighborhood I think). You can only push risksto lower & lower probability, and it makes no sense to focus on a single risk and spend time and effort to push it toorders of magnitude lower probability than all the other risks in the system. (As long as there are risks at orders ofmagnitude higher priority, those should get the time & expense.) > And that's been my point all along, despite people trying to dilute it > with nonsense numbers that they don't understand... No, it hasn't been your point all along. Your point has shifted twice now as you've been shown to be wrong about the odds.And the numbers used are not nonsense at all. All of which somewhat contradicts your statement that your "head is totallywrapped around probability" ;-) Added to your apparent ignoring of other error sources in order to focus on one extremelyunlikely one, well... > And also, if your entire solution to that risk is to rollback the > transaction in the event of a conflict, then your application is simple > enough that UUIDs are overkill anyway. I kind of doubt that the person who posted that intended it as the entire solution. It seemed to me that was intended asjust the event that triggers conflict resolution and the next step would be to inform the device that the conflicting recordis getting a new UUID, update appropriately, and so on. Just so you know, I'm done talking to you. Your arrogance, rudeness, insults, condescension and personal attacks are notsomething that I will deal with anymore. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice
В списке pgsql-general по дате отправления: