Как писать программу для работы с БД без QSqlRelationalTableModel?

[Пытон]

Поскольку эта свинина (QSqlRelationalTableModel) не желает показывать строки из БД в которых в ключевом поле хранится NULL, либо же значение не совпадающее ни с одним ключом из связанной таблицы, есть желание попробовать написать простенькую программку для работы с БД без свинины. Вдобавок, эта свинина не желает добавлять QSqlRecord в БД, пока не впихаешь вручную в эту record ключевые поля. Оне, отчего-то, не желают самостоятельно корректно создаваться в записи, которую ты создаёшь из этой же чёртовой свинины.

Ежели кому не лень, набросайте небольшой алгоритм. Имею ввиду - словами, а не кодом. Хотя, если у кого есть пример кода - не стесняйтесь, выкладывайте.

Допустим есть две таблицы: people (id, fio, id_gorod) и gorod (id_gorod, name). Связаны по полю id_gorod

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

Что использовать для первой формы? QSqlQueryModel? Ведь мне нужно все цифры из поля id_gorod заменить на соответствующее поле name из таблицы gorod.

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

А когда вторая форма будет закрыта и произойдёт возврат к первой форме, мне заново делать select для модели, дабы она отобразила изменения? А как заставить её выдать именно те строки среди которых должна оказаться и вновь изменённая запись?

П.С. Ненавижу QSqlRelationalTableModel! Она мне всю жизнь испортила!    (шутка, но с долей правды)

[Bepec]

слишком эмоционально чтобы быть правдой )

Я бы склепал самопальный вариант минут за 40. На чистых запросах.

Элегантных решений не вижу.

[Пытон]

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

[Bepec]

Хм. Я жеж написал свой вариант решения (ручками и запросами).

У вас там мутная какая то ситуация с таблицами

И да, псевдокод, как просил:

SELECT p.id, p.fio, g.name,p.id_gorod FROM people p, gorod g WHERE p.id_gorod=g.id_gorod;
По идее этот запрос должен вернуть сформированную таблицу с необходимыми вам полями ид, фио, имя города, ид города. Скрываем колонку с ИД города при необходимости (я просто не уверен, что без этого поля запрос выполнится так, как я хочу. Тестить не на чем )


Тыкаем на элемент, запоминаем положение курсора, открываем красивую формочку. В ней маппер + 1 поле с рукописным обработчиком. Редактируем. Маппер сохраняет, рукописный обработчик сохраняет.

Повторяем запрос, устанавливая курсор на предыдущую позицию.
SELECT p.id, p.fio, g.name,p.id_gorod FROM people p, gorod g WHERE p.id_gorod=g.id_gorod;

[Пытон]

А итить твою ж в коромысло!!!
MyModel = QtSql.QSqlRelationalTableModel
MyModel.setJoinMode(QtSql.QSqlRelationalTableModel.LeftJoin)
или
MyModel.setJoinMode(0)что то же самое.
и свинина показывает строки с NULL в ключевых полях!!!

Доступно, начиная с Qt 4.8, с которой я, блин, и сижу...

Теперь осталось как-нибудь программно впиндюрить значение в ключевое поле в QSqlRecord, без нелогичного программного добавления в него ключевых полей, которые в нём и так ведь есть; и жизнь будет налаживаться.

П.С. А в псевдокоде маппер-то с чем связывается? Куда он сохраняет? В SqlQueryModel? Э-э-э... сие возможно?

[Bepec]

Ахз. Я всё больше убеждаюсь, что проще запросами работать.  Ибо заготовки Qt для sql всё больше кажутся какими то... не рассчитанными на нормальную работу

[Пытон]

А я всё ещё жду и надеюсь узнать, к чему приделывать маппер-то? Разве он будет работать с QSqlQueryModel?

[Bepec]

а можно попробовать и узнать

[Странник]

предпочитаю QSqlRelationalModel не использовать - едва задача выходит за рамки стандартной примитивной, вы натыкаетесь на неизбежные ограничения. поскольку абсолютное большинство моих программ пишутся под конкретную СУБД, решаю проблему ее средствами:
1) на сервере создается представление (view), нужным образом объединяющее исходные таблицы
2) если данные необходимо редактировать посредством представления, на нем создаются соответствующие триггеры
3) в программе работаем с созданным представлением, используя QSqlTableModel и QWidgetMapper

[Пытон]

А можно хотя бы один пример ограничения?

[Akon]

Перефразирую автора - "Как писать программы без всяких там SQL моделей". Переспективный вариант на сегодняшний день - ORM. Я как-то задавал здесь вопрос про опыт использования ORM, так вот, я попробовал (ORM ODB). В целом, понравилось. Конечно, если нужна какая-то сложная логика на сервере или сложные запросы, то опускаемя обратно до SQL. Но достоинств тоже куча. В моем (относительно несложном) случае использование ORM было оптимально.

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

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