просмотр таблицы с меняющимися данными, запоминание и выделение тек строки Опции

[Steklova Olga]

Всем привет!
Есть у меня две таблицы БД: T1 и T2, в каждой есть поля ID INTEGER (PK, автоинкрементное) и PARAM FLOAT. Для работы с таблицами использую QSqlTableModel и QTableView.

Во время работы программы в таблицу T1 записи только добавляются.
Организую заполнение и просмотр следующим образом:
- при поступлении первой записи добавляю ее в таблицу БД, выполняю select для модели, первую строку таблицы делаю текущей, запоминаю соотв. значение ID,
- при поступлении следующей записи добавляю ее в таблицу БД, выполняю select для модели, строку с запомненным ID делаю текущей, делаю скроллинг отображения для обеспечения видимости текущей строки,
- при изменении текущей строки оператором запоминаю значение ID. Тут все OK.

А вот с таблицей T2 посложнее...
Во время работы программы, периодически (вероятно, не чаще, чем 1 раз в 5 сек), для занесения в таблицу T2 приходит сразу целый массив записей (размер массива - от одной до 200 записей). Мне надо хранить в БД данные только последнего массива.
Данные разных массивов:
- могут полностью совпадать,
- могут отличаться всеми значениями,
- могут отличаться несколькими значениями,
- могут отличаться количеством значений.
Организую заполнение и просмотр следующим образом:
- при поступлении первого массива добавляю поступившие записи в таблицу БД, выполняю select для модели, первую строку таблицы делаю текущей,
- при поступлении следующего массива удаляю все записи из таблицы БД, добавляю поступившие записи в таблицу БД, выполняю select для модели, первую строку таблицы делаю текущей (пока так).

Как здесь просматривать таблицу с запоминанием и выделением текущей строки?
1) Запоминать ID текущей строки? Здесь это не поможет, так как поле автоинкрементное.
2) Сделать поле ID не автоинкрементным, не удалять предыдущий массив и добавлять новый, а обновлять массив? Этот вариант мне совсем не нравится, по-моему, он очень сложный.
3) Запоминать PARAM текущей строки, а при поступлении следующего массива искать в нем запись с запомненным PARAM и делать ее текущей? А если такая не найдется, то делать текущей первую. Но для этого придется сравнивать значения типа FLOAT, видимо используя какую-то точность сравнения. Или так и надо?
Других вариантов не придумала. У кого какие мысли есть по этому поводу? Спасибо.

[Steklova Olga]

Таблицы Т1 и Т2 - это один пример,
таблица БД с полями ID, PARAM, FINT1, FINT2, FSTR - это таблица Т3, другой пример.
В T1 записи только добавляются,
в T2 удаляются старые записи и добавляются новые,
в Т3 записи добавляются или обновляются в зависимости от поступившего ID
(UPDATE OR INSERT INTO T3 ... MATCHING (ID)).

Ты же вроде бы писала, что T2 ты очищаешь и вставляешь данные по новой. Т. е. в этом случае у тебя только 1 sql для удаления и 1 для вставки.

Да

Как использовать биндинг вроде очевидно

Так как в Т2 все поля обязательные, то для Т2 - да, очевидно.

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

Здесь я говорю о Т2. А под словом "обновится" я подразумеваю не то, что я делаю таблице UPDATE, а то, что меняются данные поступающего массива, например.
Поступает 1-й раз массив со значениями PARAM (1.23, 2.34, 300.45, 445.00),
оператор начинает его просмотр,
делает текущей запись со значением 300.45,
поступает 2-й раз массив со значениями PARAM (1.23, 2.34, 300.45, 1888.00),
<здесь я перерисовываю таблицу, но хочу, чтобы текущей осталась запись со значением 300.45>,
поступает 3-й раз массив со значениями PARAM (1.23, 2.34, 300.45, 1888.00, 2001.45),
<здесь я перерисовываю таблицу, но хочу, чтобы текущей осталась запись со значением 300.45>.

Почему тогда просто не привязываться к порядковому номеру и верхней видимой строке?
Других-то ориентиров у пользователя всё равно нету...

В соотв. с выше написанным, мне надо привязываться не к ID, а к PARAM, ориентир - это PARAM.

Но я-то хочу во всех случаях (для Т1, Т2, Т3 и любых других моих таблиц, в том числе с любым количеством необяз. полей) использовать одну функцию формирования запроса.
Поэтому я и пишу s.setNum(d, 'f', 15).

Читаю дальше Ваши предложения...

Но даже если рассматривать более общий случай, который ты описываешь, то можно использовать биндинг несколькими способами:
1. Генерить параметрический sql (без данных) для каждого случая.

Если я Вас правильно поняла, то в этом случае для Т3, в которой четыре необяз. поля, придется писать 16 параметр. sql (все комбинации).

2. Использовать всегда полный insert/update с биндингом а в триггерах разбираться какие реально поля изменяются

Я пока не настолько сильна в триггерах, чтобы такое написать. Пока что, использую триггеры только для генераторов.

3. Вынести логику разборок с данными на сервер - в сохранённую процедурку.

Очень хорошо, а что будет в этой хранимой процедуре? Не могли бы Вы, Tonal, если не жалко, набросать код для случая обновления данных в таблице Т3?

Да и в 1ом случае можно добавить систему кеширования позволяющую воспользоваться этими преимуществами.

А эти слова для меня вообще пока как китайская грамота.