QDataMaper и Битовые поля в CheckBox, Мапинг битовых полей из short в БД Опции

[JohnZ]

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

Прошу прощения, я видимо Вас перепутал с другим участником форума, lanz-ом. Sorry ...
Это он мне помогал с решением проблем, описанных выше ...

Позвал телепатов, они предполагают, что проблема именно в том, что

значения нескольких QCheckBox-ов упакованы в ОДИН uint32

то есть, вместо нескольких полей в БД, как это было бы правильно, используется одно поле, в котором отдельные биты - это отдельные данные

Да, именно так. Множество бит данных, по которым с вероятностью в 95 % не будет "прямых" SQL-выборок.
Это позволяет укоротить запись в таблице, со всеми вытекающими ...
5 % - ? Дык SQL уже умеет работать с битами через встроенные функции

Телепаты наметили несколько путей решения проблемы:

путь 1) переконвертировать таблицу БД и разбить скомканное поле на отдельные поля (идеальный вариант, как по мне. Но требует переработать все запросы, которые касаются данного поля)

Такой вариант присутствует в т.ч. на тех полях, которые с высокой долей вероятности могут оказаться в условии
выборки из таблицы БД.

путь 2) в конструкторе диалога для каждого мапленного виджета добавить (setProperty) свойство (bitIndex) и как-то это дело обрабатывать на отрезке пути "виджет"<-->"record" (тут телепаты за нехваткой знаний о QDataWidgetMapper умолкают)

путь 3) телепаты знают, что все кутешные SQL-модели предназначены для самых банальных случаев с небольшими объёмами данных. И телепаты предлагают использовать старый добрый советский способ: обработать событие изменения QSpinBox, достать запись из БД по текущему ID, разложить поля в виджеты. Если что-либо редактируется, взводится какой-то флажок. Если есть попытка сменить запись, когда есть редактирвоанные данные, то запись сначала перезаписывается новыми данными

У меня весь проект на этих моделях, и почему "SQL-модели предназначены для самых банальных случаев с небольшими объёмами данных" ? Тесты на объёмах 20...50 тыс записей (накладные) на Расбери 2 показал вполне приемлимый, для комфортной работы юзверя, результат. На больше пока не претендую На Расбери 4 и современных х86, по понятным причинам он ещё лучше.

[Алексей1153]

JohnZ, значит, нагрузка не интенсивная. Да и 50кил записей - это не так уж и много

про сложность запроса - сам видишь, какие костыли намечаются

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