Re: UUID column as pimrary key?

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: UUID column as pimrary key?
Дата
Msg-id 87vd22asc2.fsf@cbbrowne.afilias-int.info
обсуждение исходный текст
Ответ на UUID column as pimrary key?  (Dennis Gearon <gearond@sbcglobal.net>)
Ответы Re: UUID column as pimrary key?
Список pgsql-general
wmoran@potentialtech.com (Bill Moran) writes:
> If the chance of a duplicate is 1 in a hundred gazillion, then I can
> still hit a dupe the VERY FIRST TIME I USE IT.
>
> I'm writing software that is intended to be used to save lives in the
> event of an earthquake or flood or cosmic ray flipping bits or any
> other massive disaster.  The last thing I need while a bunch of EMTs
> are digging bodies out of the rubble trying to save their lives is to
> need to resolve a key conflict with a bunch of mobile devices, most of
> which are not reachable because the cell network is down because of
> the disaster.  There's going to be enough other shit going wrong ...
> my software is supposed to be part of the solution.
>
> 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.

If your system is sufficiently negligently designed that this particular
conflict causes it to kill people, then I wouldn't be too inclined to
point at this issue with UUIDs being the Real Problem with the system.

This is NOT the only risk that the system faces; you can't get *nearly*
as low probabilities attached to hardware and network issues such as:
 - Disks failing
 - Cosmic rays twiddling bits in memory
 - Network connections failing part way through the work
 - Dumb techs blindly cloning the same "host key" onto every one of the
   EMTs' data collection devices

That last item is an argument in *FAVOR* of using UUIDs for the "EMTs
digging bodies out of rubble" scenario...  The typical alternative to
UUIDs would be to have (Sequence + Host Data), and I'd expect there to
be a considerable risk of Dumb Techs making mistakes there.  It wouldn't
be difficult for such a scenario to induce systematic key collisions.

It's never just about one risk; it's about *all the risks.*

> And that's been my point all along, despite people trying to dilute it
> with nonsense numbers that they don't understand: UUIDs are sufficiently
> unique for 99.99999999999% of the applications out there.  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 your application is so fragile that it cannot tolerate *that* tiny
risk, then I have to wonder if your system isn't Just Plain Too Fragile,
because there are other unavoidable risks likely to be of much greater
probability.
--
"Have  you noticed   that,  when we were   young,  we were   told that
`everybody else   is doing  it' was   a  really  stupid reason  to  do
something,  but now it's the standard  reason for picking a particular
software package?" -- Barry Gehm

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Satterwhite
Дата:
Сообщение: Re: Help with trigger
Следующее
От: Scott Ribe
Дата:
Сообщение: Re: UUID column as pimrary key?