Здравствуйте, сообщество pqsql-ru-general и Alexander.
AMP> On Fri, Jan 21, 2005 at 02:52:01PM +0500, Mihail Nasedkin wrote:
>> NG> Хрянятся в таблице, как еще один столбец. Узнать перед вставкой -- вряд
>> NG> ли, особенно в многопользовательской среде.
>>
>> Это понятно всем, но в какой системной таблице хранятся ВСЕ OID's, а
>> не только этой таблицы. Есть таблица "pg_catalog.pg_attribute" с полем
>> "attrelid", где хранятся все системные OID's, но нужны именно
>> пользовательские OID's.
AMP> attrelid в данном случае - лишь ссылка на pg_catalog.pg_class.oid.
AMP> ВСЕ системные таблицы имеют столбец oid, и именно это его основное
AMP> назначение.
>> NG> А зачем все это? Я вот с радостью отключил OID по дефолту в 8.0, ибо
>> NG> надобность в них сомнительная.
>> Мое мнение в том, что система уникальности записи в пределах всех баз
>> данных конкретной инсталляции PostgreSQL независимо от принадлежности
>> к конкретной таблице является интересным для нестандартных решений в
>> приложениях. Конечно можно такую задачу решать каждому разработчику
>> своими силами и это реализовано в других SQL-серверах.
>> Однако, если уникальность уже реализована на системном уровне сервера - это большой
>> плюс PostgreSQL. Я всегда использую OID's.
AMP> Чем не вариант - уникальность с помощью SEQUENCE, тоже на уровне сервера?
AMP> Конечно, между базами уникальности не получится, а вот между всеми
AMP> таблицами в базе - вполне. К тому же, если не ошибаюсь, oid - поле
AMP> 32-битное, тогда как значение в SEQUENCE - 64-битное, что даёт бОльшую
AMP> гарантию, что значение не переполнится на больших объёмах данных.
4 биллиона уникальных значений зачастую достаточно :)
AMP> И можно заранее достать значение, которое больше никем использовано не
AMP> будет.
Частные решения конкретного программиста останутся с ним, а системный
подход может пригодится для всех.
--
С уважением,
Mihail mailto:m.nasedkin.perm@mail.ru
