Uzhast писал(а) 25. Октября 2007 :: 12:17:

Есть еще объект.Удалить(1).
И алгоритмы, которые отвечают, за то что делают, когда делают ЭТО

Цитата:

Я не считаю, я думаю
Не знаю, честно.
Серверные курсоры - это же еще и память. Много ее надо?
А что вообще даст использование курсоров, почему лучше будет?

Цитата:


Погоди-ка, ты все-таки имеешь в виду, что ключ порядка в одбц провайдере не используется для упорядочивания, или предлагаешь разделить функции упорядочивания и идентификации строки?

kms писал(а) 25. Октября 2007 :: 12:35:

Эти алгоритмы маргинальные и вряд ли используются для удаления, например, элементов из справочника товаров или клиентов в работающей базе. Подобные вещи, скорее, для каких-то служебных целей применяются и вряд ли пересекаются с задачами, которые решаются при помощи ТП. Однако, надо бы посмотреть, что в таком случае будет с провайдером... Если результат неудовлетворительный, то придется переходить на ID. Если же, например, произойдет простой переход в самое начало таблицы, то и хрен с ним. Просто физический номер - это быстрее, чем установка упорядочивания по ИД+поиск нужного ИД+установка упорядочивания по текущему критерию выборки.

kms писал(а) 25. Октября 2007 :: 12:35:

А я тоже не знаю   Но вроде бы курсоры позволят перейти на нормальную прокрутку, а запросы вряд ли.

kms писал(а) 25. Октября 2007 :: 12:09:

Ну, почему не используется, используется. Я просто хочу сказать, что поле идентифицирующее запись в ТП совершенно не обязательно должно быть связано с тем, как провайдер выбирает записи из своего источника данных.

kms писал(а) 25. Октября 2007 :: 12:35:

Вообще, как я понимаю, существуют два ключа: "ИДПоле" - поле, которое используется в ТП и использующем его клиентском коде для идентификации записи. И "КлючПорядка" - выражение, которое позволяет упорядочить записи и ОДНОВРЕМЕННО служит внутренним ключом записи для провайдера (как я понимаю). Ну вот я и считаю, что такое двойное использование выражения упорядочивания не обязательным. Особенно в ДБФ. Тем более, что индексы там не всегда такую двойную нагрузку разрешают

Uzhast писал(а) 25. Октября 2007 :: 12:50:

Да, это один момент.

Второй момент такой.
ТП может сохранять значение строки (CDataRow*), которое потом может использовать для сравнения на равенство с другой строкой.
Если сравнение реализовано некорректно (например, только по физическому адресу записи), то быть беде.

Предположим, мы используем физический адрес записи, как ид-поле.
ТП сохраняет строку (адрес записи).
Другой клиент удаляет строку (физически строка, конечно, просто помечается как удаленная).
Третий создает новую запись (и по несчастливому стечению обстоятельств она попадает на то же самое место)
ТП просыпается и, к примеру, удаляет (гусары, молчать), данную физическую строку.
При этом она честно проверяет, что новая строка равна старой, но сравнение адресов записей всегда возвращает равенство.

Т.е. имхо включение адреса физической записи для формирования уникального ключа - небезопасная операция.

kms писал(а) 25. Октября 2007 :: 13:41:

Да, это может быть.

kms писал(а) 25. Октября 2007 :: 13:41:

Можно попробовать оценить, насколько это опасно. Может быть, все не так страшно...
Поиск по CompareRows дает следующие места, где используется сравнение:

ActivateRow - используется при помощи вызова из клиентского кода или из провайдера для изменения текущей строки. Если ТП может найти среди видимых строк требуемую, активирует ее, если нет - то производит выбор строк из провайдера, начиная с запрашиваемой для активации. Итак две ситуации: строка есть среди видимых - простая подсветка, строки нет - подгрузка. Как может быть получена строка для активации? Клиентский код определяет требуемый элемент справочника или документ, провайдер на основе этого элемента делает поиск по ИД и получает физ.номер записи. При замене удаленной записи проблемный эффект можно возникнуть только, если среди видимых есть старая запись. Тогда она подсветится, хотя реально запрашивается совсем другая - новая.

Drag'n'Drop
Сравнение используется, насколько я понял, для оптимизации отрисовки текущей цели. Тут не может произойти что-то опасное, потому что строки ТП при этом не удаляются и не создаются. Сравниваются между собой строки, полученные из одной выборки.

Так что с моей кочки зрения, сильных отрицательных эффектов быть не должно. Собственно, он только один - подсветка устаревшей строки при активации строки по запросу от клиента или от провайдера. Этот отрицательный эффект полностью нивелируется ТП с автообовлением.

Возможен еще один эффект - при обновлении строк. ТП запрашивает N строк, начиная с некоторой данной (первой видимой). Если провайдер использует физ.номер, то он возьмет N строк начиная от новой строки. Если провайдер не использует физ.номер, а использует ИД, то он не найдет строку вообще и ему придется что-то сделать по умолчанию - например перейти в начало таблицы. В любом случае то, что произойдет - нельзя считать нормальным поведением с точки зрения пользователя

Так что физномера - не такая страшная вещь, как кажется.

Не, ну конечно использование физномеров - не такое гладкое решение, как использование ИД. Но с другой стороны номера должны работать гораздо быстрее... Хотя тут надо бы еще подумать...

kms писал(а) 25. Октября 2007 :: 13:41:


Ни фига не понял как новая запись может попасть на  строку, которая в ДБФ - DELETED(),
но тем не менее занимает место в таблице.

Разве что адреса берутся при включенном фильтре NOT.DELETED().

[quote author=kiruha link=1192855975/45#55 date=1193327958]Ни фига не понял как новая запись может попасть на  строку, которая в ДБФ - DELETED(),
но тем не менее занимает место в таблице.
[/quote]

Чтоб было понятнее, вот простой тест.
[tt]
Процедура Заполнить()
     _о =СоздатьОбъект("Справочник." +Вид()); // это была форма списка нового справочника
     _о.Новый();
     _о.Код =1;
     _о.Записать();
     _о.Новый();
     _о.Код =2;
     _о.Записать();
     _о.Новый();
     _о.Код =3;
     _о.Записать();
     _о.НайтиПоКоду(2);
     _о.Удалить(1);
     _о.Новый();
     _о.Код =4;
     _о.Записать();
КонецПроцедуры
[/tt]
Порядок будет 1, 4, 3; удаленных записей нет. (на 7.7 R27)

[sub]
Если у кого есть желание - пусть обосновывает, с меня за 10 лет хватит  8-)
[/sub]

Но случай все же экзотический.
С тем же экзотическим случаем ничто не мешает сделать Id не уникальным (средствами OLEDB).

Имхо - не стоит ради этого жертвовать производительностью.