Russian Qt Forum

Наверно я не понимаю концепций MVC, но такой вот вопрос:

Возьмем простейшую базу данных:
таблица Писатель с полями id, ФИО, год рождения и т.д.
таблица Книга с полями id, Название, id_писателя и т.д.

Раньше у меня все это красиво хранилось в виде
struct Писатель
{
 string ФИО;
 int год рождения;
};

struct Книга
{
 string Название;
 int id_писателя;
};

map<int, Писатель> Писатели; //где int - id писателя
map<int, Книга> Книги; //где int - id книги

и я мог удобно получить как данные о всех писателях, так и о написавшем книгу (Писатели[Книга[n].id])

Вопрос: могу ли я просто реализовать аналогичное на моделях?

PS: извиняюсь за косноязычность

to be continued...
в простешем случае MVC ставит соответствие вьюху одной таблице. Чтобы объединить несколько таблиц, нужно придумать правила по которым они отобразятся в одну. В вашем примере можно сделать дерево глубиной 2: корни - писатели, листья - книги.
Также можно оставить 2 таблицы. Еще можно сделать таблицу книг, в которой один из столбцов - писатель. Всё зависит от того, какую информацию вы хотите преподнести пользователю.

а еще бы вопрос всетаки услышать ))

Я хочу при выборе книги выводить данные ее писателя по его id

ну так в чем проблема? Модель берет данные из таблицы (массива, списка) с книгами. При даблклике (или чем нибудь еще) показываем данные по ид из списка с авторами

QSqlRelationTableModel ?

В таком случае происходит дублирование данных (они хранятся как в модели, так и в векторе/списке/мапе).
Смысл тогда в MVC? Никак не пойму идеологию.
Приходится писать костыли, чтобы можно было работать в Qt.

Модель это лишь абстракция над вектором/списком/мапой/БД, и данные хранятся не в модели, а в том с чем работает эта модель.

Можно написать кривую модель которая будет дублировать в себе все данные и к тому же тормозить, можно нормальную которая будет только брать данные откуда они хранятся - автору рекомендую подробно изучить доку в ассистенте и особенно примеры - таки как simpleTreeView модель, но вообще если речь о связи двух таблиц по вторичному ключу - (таблица книг имеет вторичный ключ на таблицу писателей) то как и было предложено выше должно хватить QSqlRelationTableModel или QSqlTableModel с делегатом отображения/выбора писателя... Автор у вас вероятно нехватка знаний реляционных БД раз вы структурами ранее эту задачу решали, если вы четко понимаете что такое один к одному, один ко многим, многие ко многим - то все решите!