Re: Avoiding surrogate keys
От
Merlin Moncure
Тема
Re: Avoiding surrogate keys
Дата
Msg-id
z2nb42b73151005040716rcafdfff7scc1ec0f96b11ca92@mail.gmail.com
Ответ на
Re: Avoiding surrogate keys (Merlin Moncure)
Список
Дерево обсуждения
Avoiding surrogate keys Thom Brown <thombrown@gmail.com>
Re: Avoiding surrogate keys Bill Moran <wmoran@potentialtech.com>
Re: Avoiding surrogate keys "Joshua D. Drake" <jd@commandprompt.com>
Re: Avoiding surrogate keys "Joshua D. Drake" <jd@commandprompt.com>
Re: Avoiding surrogate keys Bill Moran <wmoran@potentialtech.com>
Re: Avoiding surrogate keys Alvaro Herrera <alvherre@commandprompt.com>
Re: Avoiding surrogate keys Merlin Moncure <mmoncure@gmail.com>
Re: Avoiding surrogate keys Martin Gainty <mgainty@hotmail.com>
Re: Avoiding surrogate keys "Mark Watson" <mark.watson@jurisconcept.ca>
Re: Avoiding surrogate keys John R Pierce <pierce@hogranch.com>
Re: Avoiding surrogate keys Merlin Moncure <mmoncure@gmail.com>
Re: Avoiding surrogate keys Merlin Moncure <mmoncure@gmail.com>
Re: Avoiding surrogate keys Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Avoiding surrogate keys Richard Broersma <richard.broersma@gmail.com>
Re: Avoiding surrogate keys Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Avoiding surrogate keys Philippe Lang <philippe.lang@attiksystem.ch>
Re: Avoiding surrogate keys Lew <noone@lwsc.ehost-services.com>
Re: Avoiding surrogate keys Merlin Moncure <mmoncure@gmail.com>
Re: Avoiding surrogate keys Rich Shepard <rshepard@appl-ecosys.com>
Re: Avoiding surrogate keys Merlin Moncure <mmoncure@gmail.com>
Re: Avoiding surrogate keys "Joshua D. Drake" <jd@commandprompt.com>
Re: Avoiding surrogate keys "Joshua D. Drake" <jd@commandprompt.com>
Re: Avoiding surrogate keys Thom Brown <thombrown@gmail.com>
On Tue, May 4, 2010 at 9:40 AM, Merlin Moncure wrote: > On Sat, May 1, 2010 at 4:14 PM, John R Pierce wrote: >> >> If your 'natural key' is a large text field, I'd have to assume there's some >> point at which a surrogate index would be more efficient. Would this be >> above a few dozen characters, or a few 100 characters? I wouldn't want a >> PK based on a multi-K byte text field for a table that has many 10s or 100s >> of 1000s of rows, for sure. one more note about this. if you truly have a situation where a multi kilobyte chunk of data is the key, you can always digest it and use that. you lose the natural ordering -- but in these type of cases it usually doesn't matter. merlin
В списке pgsql-general по дате отправления
