Re: question on serial key
От | Jasen Betts |
---|---|
Тема | Re: question on serial key |
Дата | |
Msg-id | gvgo4t$akh$1@reversiblemaps.ath.cx обсуждение исходный текст |
Ответ на | question on serial key (Brandon Metcalf <brandon@geronimoalloys.com>) |
Список | pgsql-general |
On 2009-05-22, Brandon Metcalf <brandon@geronimoalloys.com> wrote: > g == gryzman@gmail.com writes: > > g> you should use it, whenever you need db to keep its own key internally. > g> Advantage of sequence is also the fact, that you can have the sequence > g> value used on different columns/tables . > > g> My rule of thumb is , in that case: as long as it is a short type (not > g> of toastable, or/and variable length), and as long as it won't change, > g> and is unique - I can use it. Otherwise, I use sequence to connect > g> rows internally for database. > g> First rule, is because of index access, and the way btree works. > g> Second is, because update of value will update other rows too - and > g> HOT won't help you here, so that's not efficient. And also, forcing it > g> to be unique is harder than. > > g> Hth. > > That does help. So, in my example of a table consisting of rows for > each periodic table element, the atomic number would suffice as a > unique key since, well, it's unique and not going to change. Right? Well, until some fool* wants to insert a row for deuterium into your table, and finds that spot taken by hydrogen. If you can guarantee that you chosen natural key is sufficient and i s not going to give trouble in the case of marriages, isomerism, twin birth, isotopes, centegenarians, or some other condition that makes a mockery of your chosen key then go for it. *assuming you want it to be fool-proof.
В списке pgsql-general по дате отправления: