![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Можно ли узнать номер физической записи...
Piter © (2004-08-05 17:17:00)в SQL базах?
Например, можно это сделать в Firebird, MSSQL?
Rule (2004-08-06 14:23:00) [1]s999 (06.08.04 14:15) [35]
Спасибо, много интересного :)
s999 (2004-08-06 14:15:00) [2]
> А у Вы когдато потели над этим, если да то интересно было
> бы взглянуть ...
Достаточно посмотреть на "потение" Джефа :)
Открой IBTable.pas, IBCustomDataSet.pas. Ключевые слова для поиска и анализа:
'IBX_INTERNAL_DBKEY'
'RDB$DB_KEY'
TIBDBKey
DBKey
PIBDBKey
Rule (2004-08-06 14:06:00) [3]s999 (06.08.04 13:40) [32]
Чтобы реально использовать dbkey надо попотеть.
А у Вы когдато потели над этим, если да то интересно было бы взглянуть ...
Johnmen (2004-08-06 13:44:00) [4]>Прочитали в read, пытаемся проапдейтить запись по dbkey в
>write. Можем получить облом.
Разговор шел только о чтении.
>От абстрактного
>понятия "уникальный идентификатор записи" как то интуитивно
>ожидается несколько другое.
Естественно.
s999 (2004-08-06 13:40:00) [5]
> а у меня после выполнения запроса в поле бд_кей во всех
> записях высвечивается один и тот же символ "Ђ",вот так
А что ты хочешь от набора байт в строковом предсталении :) Это все-равно что exe в текстовом редакторе открыть и изучать. Чтобы реально использовать dbkey надо попотеть.
> + уникальность уже есть.
> Почему же нельзя считать его уникальным идентификатором
> ?
Ну, например, классическое разделение на читающую/пишущую транзакцию уже может не пройти. Прочитали в read, пытаемся проапдейтить запись по dbkey в write. Можем получить облом. От абстрактного понятия "уникальный идентификатор записи" как то интуитивно ожидается несколько другое.
Johnmen (2004-08-06 13:11:00) [6]>Я как то непонятно объясняю?
Ага.
>Это означает гарантированную неизменность значения db_Key.
+ уникальность уже есть.
Почему же нельзя считать его уникальным идентификатором ?
>А это к чему?
Да так, поинтересовался...:)
Rule (2004-08-06 12:46:00) [7]s999 (06.08.04 12:03) [26]
'select TABLE.*, rdb$db_key from TABLE'
а у меня после выполнения запроса в поле бд_кей во всех записях высвечивается один и тот же символ "Ђ",вот так
s999 (2004-08-06 12:36:00) [8]
> А как можно увидеть значение поля db_key???
"Глазами" различить вряд ли получится :) B IBX, например, используется (вариант одна таблица):
DBKey: array[0..7] of Byte;
Что там может показать контрол?
> 1. Что значит "стабилен" ?
Я как то непонятно объясняю? Это означает гарантированную неизменность значения db_Key.
> 2. Можно как-то по-другому работать с БД, вне транзакций
> ?
А это к чему?
Johnmen (2004-08-06 12:13:00) [9]>А это и означает, что db_Key никакой не индентификатор записи,
>а всего-лишь текущее расположение этой записи в базе.
1. Что значит "стабилен" ?
2. Можно как-то по-другому работать с БД, вне транзакций ?
Sirus (2004-08-06 12:09:00) [10]s999 (06.08.04 12:03) [26]
А вот теперь можем увидеть и другое значение в поле db_key.
А как можно увидеть значение поля db_key???
дело в том что я сколько ни пытался в качестве значения я получал только один символ одинаковый для всех записей (визуально, так как distinct возвращает то же самое количество записей....)
s999 (2004-08-06 12:03:00) [11]
> А что значит "db_Key стабилен только в рамках одной транзакции"
> ?
А это и означает, что db_Key никакой не индентификатор записи, а всего-лишь текущее расположение этой записи в базе. Например:
IBTrans: TIBTransaction;
IBDataSet: TIBDataSet;
IBDataSet.SelectSQL = 'select TABLE.*, rdb$db_key from TABLE'
IBTrans.StartTransaction;
IBDataSet.Open;
Допустим в TABLE одна запись.
Теперь, сколько угодно раз делаем IBDataSet.Open/Close;
всегда видим гарантированно одно и тоже уникальное значение в поле db_key.
А теперь:
IBTrans.CommitTransaction;
IBTrans.StartTransaction;
IBDataSet.Open;
А вот теперь можем увидеть и другое значение в поле db_key.
Johnmen (2004-08-06 11:36:00) [12]А что значит "db_Key стабилен только в рамках одной транзакции" ?
s999 (2004-08-06 11:32:00) [13]
> не знаток IB, поэтому вопрос, что будет после бэкап & ресторе?
>
Какой "бэкап & ресторе"? Я же сказал: db_Key стабилен только в рамках одной транзакции. Это чисто технологическая вещь, использование клиентом черезвычайно редкое. Физически, это номера страниц со смещением в базе. Такое обращение к записи является наиболее быстрым из всех возможных, фактически, это прямое обращение. Пример использования... ну, можете посмотреть исходники IBTable.
Rule (2004-08-06 08:47:00) [14]Вот процитирую из книги "Введение в Интербейз", написаной А. Я. Скляром:
"..... Порядок строк в таблице не фиксируется (таблица отражает отношение, которое яввляется множеством, а для элементов множества порядок не фиксируется). Таким образом таблица определяется составом поименованных столбцов вне зависимости от порядка их записи, а также составом строк вне зависимости от порядка их следования ..."
Это из главы "Реляционные базы данных" ...
Так что я думаю их этого можно сделать выводы ...
sniknik (2004-08-06 08:19:00) [15]> для IB он для каждой записи как бы уникальный... потому что при попытке просмотра значения этого поля у всех записей значение
> получается одинаковое...
не знаток IB, поэтому вопрос, что будет после бэкап & ресторе? частая в общемто операция. только на рабочей базе, где записи уже не раз удалялись.
а даже если это пройдет правильно то, на смене версии IB? видел рекомендации перехода на фаребирд например, бекап из старой и ресторе в другую версию.
не скажу точно но предполагаю, что будет, юзер будет после мучится и восстанавливать старую версию, как тут буквально вчера ктото писал. (если гдето есть ссылки на этот номер, про которые движку ничего не известно (ваши))
Sirus (2004-08-06 07:55:00) [16]Это и есть идентификатор записи... для IB он для каждой записи как бы уникальный... потому что при попытке просмотра значения этого поля у всех записей значение получается одинаковое...
При помощи rdb$db_key можно удалять одинаковые (multiple) записи
Piter (2004-08-06 00:20:00) [17]О! Так что такое rdb$db_key объясните плиз
s999 (2004-08-05 20:03:00) [18]
> Использовалось какое-то служебное поле... $RBC или блин
> типа того...
Ну поиграйся, если хочешь. Делается это, например, так:
select TABLE.*, rdb$db_key from TABLE
VID (2004-08-05 19:52:00) [19]Вообще то при простом запросе
Select * from table1 записи упорядочеваются именно по физическому расположению в базе, это работа плана NATURAL.
Piter (2004-08-05 19:48:00) [20]просто вот помню я попросил составить запрос. И вроде как раз Johnmen составил его, а так как я не сказал по какому полю упорядочивать, он упорядочил по физическому номеру записи. Вроде так было сказано...
Использовалось какое-то служебное поле... $RBC или блин типа того...
Речь шла о Firebird