crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
> QDataMaper и Битовые поля в CheckBox, Мапинг битовых полей из short в БД
JohnZ
  опции профиля:
сообщение 15.4.2021, 12:28
Сообщение #11


Участник
**

Группа: Участник
Сообщений: 139
Регистрация: 19.7.2014
Пользователь №: 4190

Спасибо сказали: 10 раз(а)




Репутация:   0  


Цитата(Алексей1153 @ 13.4.2021, 17:33) *
JohnZ, нет, я на самом деле не понял ТЗ )) Ты меня переоцениваешь. С классом QDataWidgetMapper ранее не сталкивался, но сейчас в справке почитал, вроде понял, для чего он - вроде как листалка записей из таблицы, при этом поля записи отображаются в нужном виджете на форме.

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

Цитата
Позвал телепатов, они предполагают, что проблема именно в том, что
Цитата(JohnZ @ 12.4.2021, 19:54) *
значения нескольких QCheckBox-ов упакованы в ОДИН uint32

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

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

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

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

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

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

У меня весь проект на этих моделях, и почему "SQL-модели предназначены для самых банальных случаев с небольшими объёмами данных" ? Тесты на объёмах 20...50 тыс записей (накладные) на Расбери 2 показал вполне приемлимый, для комфортной работы юзверя, результат. На больше пока не претендую :rolleyes: На Расбери 4 и современных х86, по понятным причинам он ещё лучше.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Алексей1153
  опции профиля:
сообщение 15.4.2021, 14:33
Сообщение #12


фрилансер
******

Группа: Участник
Сообщений: 2939
Регистрация: 19.6.2010
Из: Обливион
Пользователь №: 1822

Спасибо сказали: 215 раз(а)




Репутация:   34  


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

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

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



Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 29.3.2024, 18:52