Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
есть ли у PostGreeSQL уникальный индефикатор для каждой строки и как его выбрать? В Oracle это выглядит примерно так select rowid from table а как в PostGree? Креативу нет предела ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 16:21 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Насколько я знаю - уникальным идентификатором строки в таблице является ее первичный ключ :-) Других нормальных способов мне не ведомо :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 16:47 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Licvidator_guestНасколько я знаю - уникальным идентификатором строки в таблице является ее первичный ключ :-) Других нормальных способов мне не ведомо :-( есть еще уникальный индефикатор каждойстрок и в пределах базы данных по крайней мере такое есть в Oracle называется он RowID и выборка по этому индификатору считается самой быстрой! типа select * from table where rowid='qwedasmdj123' Вот я и хотел узнать нет ли такого в PostGre и что такое OID ???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 17:56 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
это он и есть, уникальный в пределах сервера идентификатор. З.Ы. Похоже у таблиц иожно отключить его формирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 18:51 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
А документацию почитать? Пункт 5.4 в докуметнации, входящей в комплект PostgreSQL. OID записи если есть это вроде rowid, но его может не быть, и уникален с оговорками, которые та перечислены (и OID - не только для записей, а существует и для других объектов): OIDs are 32-bit quantities and are assigned from a single cluster-wide counter. In a large or long-lived database, it is possible for the counter to wrap around. Hence, it is bad practice to assume that OIDs are unique, unless you take steps to ensure that this is the case. If you need to identify the rows in a table, using a sequence generator is strongly recommended. However, OIDs can be used as well, provided that a few additional precautions are taken: * A unique constraint should be created on the OID column of each table for which the OID will be used to identify rows. * OIDs should never be assumed to be unique across tables; use the combination of tableoid and row OID if you need a database-wide identifier. * The tables in question should be created using WITH OIDS to ensure forward compatibility with future releases of PostgreSQL. It is planned that WITHOUT OIDS will become the default. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 22:36 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Автора вопроса интерисует не наличие идентификатора записи типа OID а прямая ссылка на старницу и смещение на ней ... Поиск записи по OID - при отсутствии индекса идет перебором по всей таблице... в постгресе же есть дополнительны скрытые поля таблиц одно из них ctid это есть указатель на физическую запись - т.е. если у вас есть информация о физическом расположении записи то вы можете используя выражение where ctid=... найти нужную запись практически мгновенно... но надо помнит что после вакума - может поменяться и физическое расположение записи... вот цитата из доки\ ctid The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change each time it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 10:59 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
domanixАвтора вопроса интерисует не наличие идентификатора записи типа OID а прямая ссылка на старницу и смещение на ней ... Поиск записи по OID - при отсутствии индекса идет перебором по всей таблице... в постгресе же есть дополнительны скрытые поля таблиц одно из них ctid это есть указатель на физическую запись - т.е. если у вас есть информация о физическом расположении записи то вы можете используя выражение where ctid=... найти нужную запись практически мгновенно... но надо помнит что после вакума - может поменяться и физическое расположение записи... вот цитата из доки\ ctid The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change each time it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows. т.е. я так понимаю в пределах одной таблицы ctid не повторяютя ??? и запрос типа select ctid from client2 where ctid=(0,1) будет выполняться пределно быстро ? да и еще а как написать правильно where просто where ctid=(0,1) не работает ! ??? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 11:21 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
SELECT ctid, * FROM test WHERE ctid = '(1,116)'::tid; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 12:21 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Licvidator_guestНасколько я знаю - уникальным идентификатором строки в таблице является ее первичный ключ :-) Других нормальных способов мне не ведомо :-( Почему не использовать превичный ключ? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 12:43 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Niemi Licvidator_guestНасколько я знаю - уникальным идентификатором строки в таблице является ее первичный ключ :-) Других нормальных способов мне не ведомо :-( Почему не использовать превичный ключ? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Да потому что я не пользуюсь первичными ключами ! Я использую поле + уникальный индекс! Это первое! И иногда нужно текущую строку бысто изменить!!! Подход в каждой таблице первичный ключ меня не устраевает! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 14:37 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
s_elected Да потому что я не пользуюсь первичными ключами ! Я использую поле + уникальный индекс! Это первое! И иногда нужно текущую строку бысто изменить!!! Подход в каждой таблице первичный ключ меня не устраевает! Тяжелый случай. Даже в Oracle rowid может меняться. Например, после выполнения update может потребоваться перемещение записи в другой блок, где достаточно пространства для сохранения всех изменений. Использование rowid для поиска записей чревато необъяснимыми исчезновениями записей при поиске. Ошибка невоспроизводимая, то есть самая дорогая по затратам на исправление. И мне известны реальные случаи, когда люди огребались по полной программе. При малых нагрузках, конечно, верятность глюков очень невелика. И если постановка задачи позволяет создать "немного глючную" базу данных... ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2005, 12:05 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Вячеслав Скорых s_elected Да потому что я не пользуюсь первичными ключами ! Я использую поле + уникальный индекс! Это первое! И иногда нужно текущую строку бысто изменить!!! Подход в каждой таблице первичный ключ меня не устраевает! Тяжелый случай. Даже в Oracle rowid может меняться. Например, после выполнения update может потребоваться перемещение записи в другой блок, где достаточно пространства для сохранения всех изменений. Использование rowid для поиска записей чревато необъяснимыми исчезновениями записей при поиске. Ошибка невоспроизводимая, то есть самая дорогая по затратам на исправление. И мне известны реальные случаи, когда люди огребались по полной программе. При малых нагрузках, конечно, верятность глюков очень невелика. И если постановка задачи позволяет создать "немного глючную" базу данных... ;) Не нужно говорить не разобравшись. Выборка по Rowid используется тогда, когда ты уже стоишь на записи и тебе нужно ее изменить а поиск по индексу будет идти дольше. Да вобще че о чем речь задачу понять надо прежде чем писать "тяжелый случай" Тяжело быть по пояс деревянным а все остальное решимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2005, 22:33 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
s_electedВыборка по Rowid используется тогда, когда ты уже стоишь на записи и тебе нужно ее изменить а поиск по индексу будет идти дольше. Эээээ... Вы не могли бы пояснить, что означает понятие "стоять на записи" по отношению к клиент-серверным СУБД? Отдаете ли вы себе отчет, что покуда вы "стоите на записи", физический адрес этой записи может измениться? Не знаю как у вас с английским, сделаю перевод одного абзаца из документации: "Обратите внимание, что несмотря на то, что ctid может быть использован для быстрого поиска строки, ctid этой строки будет изменяться каждый раз, когда строка изменяется или перемещается командой VACUUM FULL. Поэтому ctid бесполезен как долговременный идентификатор строки". Если вы "стоите на записи", то ctid используется именно как долговременный индентификатор. Покуда пользователь чешет в затылке, запись может быть изменить свой ctid, и тогда update пользователя уйдет в никуда. От себя добавлю, что и как кратковременный идентификатор ctid использовать я бы не стал. s_electedДа вобще че о чем речь задачу понять надо прежде чем писать "тяжелый случай" Фраза "Подход в каждой таблице первичный ключ меня не устраевает!" - это действительно тяжелый случай, вне зависимости от предметной области. Не устраивают человека правила нормализации, и все тут! Cool... s_elected Тяжело быть по пояс деревянным а все остальное решимо. Совершенно согласен. Сильно подозреваю, что за спиной у вас опыт фокспрошника. Иначе я не могу объяснить презрение к первичным ключам (которое меня так сильно поразило), привычка искать строку по номеру, выражение "стоять на записи" и непонимание принципов работы в многопользовательском режиме. Это вас извинило бы, кабы еще и не упертость. Тяжело вам... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2005, 08:48 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Уважаемый Вячеслав Скорых, я понимаю что свой подход всегда верный! =-) И Доказывать свою точку зрения нужно! Но людей обижать фразами "тяжелый случай" не гоже! За спиной у меня несколько очень крупных проектов вразных городах под Oracle. И никто не жалуется... По поводу первичных ключей: Читайте внимательнее я использую вместо первичного ключа слобец + уникальный индекс. это почти тоже самое за исключением некоторых моментов которые как раз мне и не нужны. RowId в оракле я использывал исключительно только как временный идентификатор это раз! и заботился о том, чтобы во время Update строка была блокирована! Отсюда не сложно сделать вывод. По поводу Ctid в PostGree я не спорю поэтому и задал вопрос в Топик так как очень плохо знаю СУБД Postgree. А за разъяснение по поводу выборки по CTID Вам огромное спаcибо, Буду пользоваться OID. Креативу нет предела ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2005, 11:06 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
книжка Ричард Стоунз, Нейл Мэттью - Основы PostgreSQL, стр. 244: автор В правильно спроектированной базе данных с разумно созданными первичными ключами применять OID никогда не понадобится. Этот идентификатор упомянут лишь для полноты картины, настоятельно советуем вам удержаться от искушения использовать его когда бы то ни было. т.е. хотя всем не рекомендуется так делать, но одному человеку совершенно необходимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2005, 13:20 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
Просто подход у меня такой ... Ну не люблю я первичный ключ. Еще скажу фразу которая некоторых повергнет в шок: Я не удаляю ни одной строки из базы данных только в исключительных случаях(когда сам сажусь за SQLNavigator)! Мне многие говорят "Как так?" А вот так маркирую строку (status=-1) и соответсвенно выборка идет where status>=0 Зато это меня не редко спасало. Так как некоторые горе админы иной раз такое натворят, а свалаят все на Проект (типа глючит мы не виноватые ;-) ), и ничего не докажешь никому!!! А отвечай за это все я (разработчик). Вот по этому и подход немного не стандартный. Креативу нет предела ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2005, 13:42 |
|
||
|
есть ли у PostGreeSQL уникальный индефикатор для каждой строки ?
|
|||
|---|---|---|---|
|
#18+
вообще-то судя по разговорам разработчиков они планируют уйти от OID. вроде даже в 8-ой версии в настройках что-то типа Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2005, 13:44 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=32917144&tid=2007429]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 395ms |

| 0 / 0 |
