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 по дате отправления:

Предыдущее
От: Gordon Shannon
Дата:
Сообщение: Re: walreceiver getting bad data?
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: UUID column as pimrary key?